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Ebben a hónapban talán 
túl jól is sikerült! Mármint 
hogy az a célunk, hogy 
mind a kezdőknek, mind 
a már gyakorlott rend- 
szergazdáknak, progra- 
mozóknak érdekes cikkek- 
kel kedveskedjünk. 

Az újság egyik fele szinte 
nyers szakszöveg: rend- 
szermaggal, időzítőkkel, 
megszakításkezelőkkel, 
ütemezőkkel, nyomtató- 
kapukkal foglalkozik, míg 
a másik felében olvasóink 
tovább ismerkedhetnek a rendszer 
alapjaival, a héjprogramozással, a 
SuSE- és a Debian-változatok haszná- 
latával. Sajnos ezért cserébe keveseb- 
bet foglalkozunk a hálózatokkal, in- 
kább a rendszer , mélyebb" részeire 
összpontosítunk. 

Szeretnénk pontosabban megismerni 
olvasóink véleményét, hogy mely cik- 
kek tetszettek a legjobban, hol javít- 
sunk a tartalmon, mi volt hasznos 
olvasmány, mi időrabló, van-e értelme 
a lemezmellékletnek? Sőt azt, szeret- 
nénk, ha olvasóink részt vennének a 
lap szerkesztésében is, véleményük- 


kel, javaslataikkal segítenék, hogy az 
Önök igénye szerinti magazinná vál- 
junk! A 3 www.linuxvilag.hu/kerdoiv 
címen elérhető egy kérdőív, amellyel 
az a célunk, hogy bárki elmondhassa 
véleményét, beleszólhasson a szer- 
kesztőség munkájába. Kérem, olvas- 
sák el, töltsék ki ezt a kérdőívet! 
Térjünk csak vissza még egy szösz- 
szenet erejéig e havi cikkeinkhez! 
Pontosabban a 46. oldalon kezdődő 

, személyi videófelvevő építése" 
címűhöz, ami Christian A. Herzog 
tollából származik. Hogy miért tartom 
különösen érdekesnek ezt az írást? 
Mert egy olyan lehetőséget ír le, ami 

a Linux mindennapi használhatóságát 
bizonyítja. Maholnap már idehaza is 
elérhető a DVD-író, főleg, ha arra 
gondolunk, hogy egy Linux egy 
DVDáíróval lényegesen magasabb 
minőségű szolgáltatást képes nyújtani, 
mint egy sokkal többe kerülő , videole- 
mez-lejátszó és -felvevő" doboz. Ráérő 
érdeklődők ma már egyetlen számító- 
gépből álló házimozirendszert is 
gyárthatnak maguknak. Még azokon 
a bosszantó ventilátorokon kell dol- 
gozni, és a feleségek is megkedvelik 
kedvenc pingvinünket! 
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Programvadászat 


Tűzróka 

A Mozilla-projekt ismét meglepetést 
okozott: az eddig FireBird (I űzmadár) 
névre hallgató böngészőprogram a 
0.8-as változathoz érve FireFox (Tűz- 
róka) névre kereszteltetett át, mivel 
ilyen nevű program már létezett. Mint 
azt a 5 http:/firebird.sourceforge.net/ 
oldalon is olvashatjuk, a FireBird 
adatbázis-kezelő csapata üdvözli ezt a 
lépést. Ez a program használhatóságát 
természetesen nem befolyásolja, 
szerintem ez a jelenlegi böngésző- 
programok királya! 

Szinte minden böngészőt kipróbáltam 
már, de egyik sem tetszett annyira, 
mint a FireFox. Debian rendszereken 
ugyan csak a 0.7-es változat érhető el, 
emiatt sohasem a .deb csomagot tele- 
pítem, hanem letöltöm az internetről 
a tar.gz fájlt, és azt használom - így 
tettem a 0.8-as változat megjelené- 
sekor is. Mindenkinek csak ajánlani 
tudom ezt a módszert. 

A telepítés a következőkből áll: letöl- 
töm, kicsomagolom, futtatom - tehát 
nem egy ördöngösség. Ha minden 
felhasználó számára elérhetővé 
szeretnénk tenni a rendszeren, akkor 
a /opt/FireFox könyvtárat ajánlom a 
telepítéshez. Régi szokásokhoz híven 
a /opt könyvtárba mindenféle , külső" 
(tehát a rendszernek részét nem 
képező) programokat ajánlott telepí- 
teni. Nekem ebben a könyvtárban 
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vannak a legfrissebb böngészőprog- 
ramjaim, a legutóbbi OpenOffice.org 
és egy-két olyan program, amit .deb 
csomagban nem találtam. 


KOffice 


E havi korongunkon a KDE-felülethez 
szorosan kapcsolódó irodai alkalma- 
zásokat összefogó programcsomag a 
legnagyobb falat. Szövegszerkesztő 
(KWord), táblázatkezelő (KCalc), 








bemutatókészítő (KPresenter) és min- 
den egyéb olyan megtalálható benne, 
ami az irodai munkavégzéshez elen- 

gedhetetlen. Remélhetőleg mindenki 


megtalálja a megfelelőt a rendszeréhez. 


Felkerült Connectiva 9, Red Hat Fe- 
dora, SuSE 8.0, 8.2, 9.0, Slackware 8.1, 
9.0, 9.1 és forráskódváltozatban is. 
lelepíteni forráskódból a legbonyo- 
lultabb, de korántsem lehetetlen, 
amennyiben nincs más választásunk. 
Barátságos felület, nagyon jól együtt- 
működik például a Konguerorral. 





Képes előnézeti képek készítésére, 
amennyiben az egérmutatóval a 
KÖffice-hoz rendelt dokumentum 
felett állunk meg, legyen az akár 
szöveg, akár táblázat vagy bemutató. 
Az újítások között szerepel, hogy a 
KWord az OpenOffice.org 1.1-es válto- 
zatának a formátumát is képes kezelni. 
Én régebben nem szerettem a KOffice 
Workspace-felületet, ami minden ide 
tartozó programot felölel, most azon- 
ban sikerült megkedvelnem, azt az 
egy dolgot leszámítva, hogy sok 
helyet foglal el a képernyő hasznos 
felületéből. 


Rendszermag 

A legújabb 2.6.2-es rendszermag is 
helyet kapott a korongon. Fordításá- 
hoz, használatához a régebbi rend- 
szereken valószínűleg szükség lesz a 
hozzá tartozó programok fírissítésére. 
Miután a kernel-image-2.6.2-1-686 
rendszermagot telepítettem, frissí- 
tenem kellett a modconf programot is, 
mert a régi még nem volt rá felkészít- 
ve; így esett, hogy Woodyból SID lett. 


Videó 

A 40. oldalon kezdődő , Személyi 
videófelvevő készítése" című cikkünk- 
höz tartozó programok és kiegészítők 
nagy része megtalálható a Magazin/ 
Video könyvtárban. Olyan cseme- 
géket találhatunk itt — a fontossági 
sorrendet most mellőzve -, mint 
játékok (vdr-games), időjárás-jelentő 
(vdr-weather), teletext-program (vdr- 
teletext), VCD-, valamint DVD-leját- 
szó (vdr-vcd, vcd-dvd). 


Csontos Gyula 

(Csontos. Gyulaolinuxvilag.hu) 
A Linuxvilág szakmai és 
CD-szerkesztője. Szabadide- 
jében szívesen mászik 
hegyet és kerékpározik. 





Java 1.5 


A Sun Microsystems bejelentette a 
Java 2 legújabb változatát, pontosab- 
ban a Standard Edition (Tiger kód- 
nevű) 1.5-ös próbakiadását, amely a 
Java programozási nyelv legnagyobb 
frissítését testesíti meg az 1.4-es válto- 
zat két évvel ezelőtti megjelenése óta. 
Az új kiadással bővült a nyelv által 
kínált lehetőségek köre, a fejlesztők 
nagyobb teljesítményű, könnyebben 
felügyelhető, gyorsabban induló, 
kevesebb erőforrást igényelő, a multi- 
médiát jobban támogató alkalmazá- 
sokat készíthetnek - és többek között 
a felsorolt típusok és a generikus 
programrészek használatának régen 
várt lehetősége is elérhetővé vált. 

2 http:/java.sun.com/j2se/1.5.0/index.jsp 


Az első számú közellenség 

Ha a minden idők leggyorsabban 
terjedő számítógépes férgét kell kivá- 
lasztani, a MyDoom mindenképpen 
dobogós helyre jut. A január végén 
kétféle, A és B jelű változatban meg- 
jelent féreg feladata két cég weblapjá- 
nak elosztott szolgáltatásmegtagadási 
támadással történő kifektetése volt: az 
A változat a SCO, a B pedig a Micro- 
soft ellen irányult. 

A MyDoom érdekessége, hogy klasszi- 
kus értelemben véve nem nevezhető 
vírusnak, hiszen semmilyen program- 
hibát nem használ ki - terjedését az 
elektronikus levélben kapott mellékle- 
teket mérlegelés nélkül megnyitó fel- 
használók hiszékenysége alapozta 
meg. A futtatás után saját SMIP-kiszol- 
gálóján keresztül önmagát terjesztő 
férget működésének csúcsán egyetlen 
nap alatt 4,5 millió példányban fogták 
el, amivel a férges levelek a világ levél- 
forgalmának egyhatodát tették ki. 

A MyDoom február 1 és 12 között 
támadja a 3 http:/sco.com oldalt 

— tevékenységének február elején 
azonnal meg is lett az eredménye, 

a SCO weblapját kénytelen volt a 

2 http:/www.thescogroup.com cím 
alá menekíteni, míg az e téren amúgy 
is komoly erőforrásokkal rendelkező 
Microsoft oldalát az egyébként kevés- 
bé elterjedt B változat által indított 
támadás nem tudta megbéntani. 

A SCO és a Microsoft 250—-250 ezer 
dolláros jutalmat kínál annak, aki 
segít megtalálni a MyDoom - a fel- 
tételezések szerint Oroszországban 
élő — készítőjét. 
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Egyre feljebb 

Az IBM és a SuSE Linux együttmű- 
ködésének eredményeképpen az 
IBM eServer sorozatának tagjain 

és az Opteron alapú gépeken futó, 
3-as szervizcsomaggal ellátott SuSE 
LINUX Enterprise Server 8 elnyerte 
a Common Criteria szerinti 
CAPP/EAL3- minősítést (CAPP 
Controlled Access Protection Profile, 
ellenőrzött hozzáférési profil). 

Az Egyesült Államok Védelmi 
Minisztériuma és hadserege által 
megkívánt minősítések megszerzése 
nemcsak a védelmi beszerzések felé 
nyitja meg az utat a Linuxnak, de a 
kereskedelmi felhasználók számára 
is fontos üzenetet hordoz a SuSE 

és az IBM termékeinek megbízható- 
ságát illetően. 

A két cég tavaly augusztusban 
EAL2-1 minősítést szerzett, azóta az 
operációs rendszert egy biztonsági 
naplózó alrendszerrel látták el, illetve 
további szigorú próbákat végeztek 
rajta — ennek köszönhető a mostani 
előrelépés. A SuSE Linux egyben 
COE (Common Operating Environ- 
ment) minősítést is nyert, ennek 
meglétét ugyancsak az Egyesült Álla- 
mok Védelmi Minisztériuma követeli 
meg a kereskedelmi termékektől; 
előírásai a szolgáltatáskészletre és az 
együttműködési lehetőségekre vonat- 
koznak. Mindezzel a SuSE Linux lett 
az első olyan Linux-változat, amely 
COE és CC minősítést egyaránt 
kapott, és ha a két cég tervei megva- 
lósulnak, akkor rendszereik még 
komolyabb minősítési eljárásokon 

is sikerrel fognak részt venni. 


Valós időben 64 biten 


A Concurrent Computer Corporation 
bejelentette RedHawk nevű valós 
idejű Linux-változatának 2.0-s, kife- 
jezetten AMD Opteron processzo- 
rokra készített változatát. A 2.6-os 
rendszermagra épülő, a Red Hat 
vállalati terjesztéseivel együttmű- 
ködni képes RedHawk az első valós 
idejű Linux az AMD legújabb pro- 
cesszoraira. A RedHawk Linux külön- 
féle alkalmazásokban már bizonyí- 
tott, a cég Intel Xeon processzo- 
rokra épülő rendszereit repülőgép- 
szimulátorokban, távközlési rend- 
szerek kipróbálására és ipari vezér- 
lésekben használják. 

2 http:/www.ccur.com 


colinux — játékszer? 

Elkészült a coLinux, a Linux Windows 
alatti futtatását szolgáló program első 
változata. Érdekessége, 
hogy - leírása szerint — 
nem virtuális gépet 
hoz létre a gazda 
operációs rendszer 
alatt, hanem külön- 
leges illesztőprog- 
ramként működik, 
amely lehetővé teszi a 
Linux-rendszermag futtatását. 

A gazda és a vendég operációs rend- 
szer felváltva használja és egyaránt 
közvetlenül éri el a gép processzorát, 
így a vendég is közel olyan sebes- 
séggel futhat, mintha egyedül hasz- 
nálná a gépet. Mivel a coLinux a 
normál Linux-rendszerekével meg- 
egyező bináris formátumot használ, 
az alkalmazások módosítás nélkül 
futtathatók alatta. 

2 http:/www.colinux.org 





coLinux 


Megújuló OpenView 

A HP hamarosan Linuxra is átülteti 
OpenView Operations alkalmazását, 
miközben megújítja közel tízéves 
kódra épülő OpenView for Unix 
rendszerét. Az első modulok pon- 
tosan azt a területet fogják megcé- 
lozni, ahol a Linux a legerősebb - és 
ez a biztonsági felügyelet. Az Open- 
View már most is képes a linuxos 
gépek felügyeletére, ám maga a felü- 
gyeleti konzol csak HP/UX, Solaris 
vagy Windows-rendszeren használ- 
ható. A linuxos változat, bár közeli 
rokonságban áll majd vele, az eltérő 
API-k és protokollok miatt nem a 
unixos kiadás újrafordítása lesz. A HP 
várakozásai szerint a Linux egyre 
nagyobb szerephez jut majd felügye- 
leti alaprendszerként, bár az, hogy a 
Unixot képes lesz-e valaha is teljesen 
kiszorítani, nehéz megjósolni. A HP 
ezzel párhuzamosan egy ügynök 
nélküli felügyeleti rendszert is fej- 
leszt, amely a jelenlegiektől eltérően 
semmilyen alkalmazás telepítését 
nem igényli majd a felügyelendő 
gépre — mindennek a megvalósítását 
az teszi lehetővé, hogy szabványos 
felületeken keresztül az operációs 
rendszerek egyre több távolról 
használható szolgáltatást és adatot 
nyújtanak; ezek segítségével egyre 
kevésbé okoz gondot a távoli kezelés. 
9http:/www.openview.hp.com 
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0 Neill villanykabát 
Az ONeill Europe és az Infineon 
együttműködésének eredménye- 
képpen a ruházati cég 
2004/2005-ös téli kollekció- 
jában megjelenik az 
első elektronikus ruha: 
egy hódeszkások- 
nak szánt dzseki. 
A dzsekibe egy 
lapkát építenek, 
amelynek a 
tulajdonosa 
Bluetooth-kap- 
csolaton ke- 
resztül igény- 
be vehető 
telefonálási és 
MP3-lejátszási 
lehetőségre tesz szert. A , Hub" nevű 
kabát anyagába vezető tulajdonságú 
szálakat szőnek, ezek adják a lapka 
kapcsolatát a szintén szövetből készült 
billentyűzettel, a bukósisakba épített 
hangszórókkal, valamint a telefoná- 
lásához a gallérba kerülő mikrofonnal. 
2 http:/www.oneilleurope.com 








Nemzedékváltás az Intelnél 
Az Intel megkezdte legújabb Pentium 
4 processzorainak forgalmazását. 

A Prescott kódnévvel 
fejlesztett lapkák 
immár 90 nano- 
méteres eljárás- 
sal készülnek, 
és elődjeik- 
hez képes 

több fel- 

építésbeli 
változáson 
is keresztülmentek. 
A leginkább szembetűnő 
talán az, hogy az új lapkák már 1 MB 
másodszintű gyorstárral rendelkez- 
nek, de nem szabad elfeledkezni a 
13 új utasításról és a továbbfejlesztett 
Hyper-Ihreading megoldásról sem. 
A Prescott lapkák bemutatásával az 
Intel egy újabb Pentium 4 Extreme 
Edition lapkát is bejelentett, a 34 GHz 
órajelű, 2 MB harmadszintű gyorsító- 
tárral ellátott processzor feladata a 
csúcskategóriás gépre vágyó játékosok 
és egyéb profi felhasználók szívének 
a meghódítása. 
Az új processzorok az Intel 865 és 
8/5-ös sorozatú lapkakészleteivel hasz- 
nálhatók, az áruk 178 dollárról indul. 
2 http:/wwwiintel.com 
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Jó a térlátásod? 
A Sun kísérleti, különleges szemüveg 
nélkül is használható háromdimenziós 
felhasználói felületet mutatott be. 
A 3D-felület Java alapú, nyílt forrású, 
jelenleg Linuxon, X fölött fut. Segítsé- 
gével a felhasználók egészen újszerű 
módon használhatják a számítógé- 
püket: a háromdimenziós térben egy- 
más elé vagy mögé helyezhetik az 
objektumokat, oldalra tologathatják 
vagy több rétegbe szervezhetik őket. 
A Sun egyelőre hangsúlyozottan csak 
kísérletezik; a felület végleges meg- 
jelenése, fejlesztési ütemterve még 
nem készült el, bizonyos szolgáltatásai 
ugyanakkor a Java Desktop System- 
ben egy éven belül megjelenhetnek. 
A Project Looking Glass grafikus rend- 
szere nem igényli a hagyományos 
alkalmazások újraírását, azok továbbra 
is használhatják a megszokott 2D- 
megjelenítést. Futtatása természetesen 
viszonylag komoly erőforrásokat 
kíván meg: a Sun legalább 850 MHz- 
es processzort, 256 MB memóriát és 
megfelelő VGA-kártyát javasolt — igaz, 
ezeket a követelményeket ma már 
nem nehéz teljesíteni. 
A fejlesztés eredményeképpen a 
linuxos rendszerek teljesen újfajta 
felületet kaphatnak -— kérdés, hogy 
lesz-e rá igény. A jelenlegi felületek 
kétféle elgondolást követnek: vagy a 
Microsoft rendszereit próbálják meg 
utánozni, vagy valami teljesen mást 
próbálnak megvalósítani. Mivel a 
felhasználókat roppant nehéz valami 
újnak a használatára rávenni, illetve 
megértetni velük, hogy a dolgaikat 
teljesen újfajta módon rendezhetik és 
szervezhetik, az utánozás mindenkép- 
pen fájdalommentesebb eljárás — csak- 
hogy a Sun embereinek ez nem volt 
ínyükre. Munkájuk sikerét majd a 
jövő és a felhasználók döntik el. 
2 http:/wwws.sun.com/software/ 
looking glass/ 


internetezés repülőről 

A Boeing egyik leányvállalata, a Con- 
nexion by Boeing hamarosan széles 
sávú interneteléréssel szeretné ellátni 
a repülőjáratokat. A szolgáltatással ter- 
mészetesen elsősorban a vállalati fel- 
használókat célozzák meg, akik az in- 
ternethasználati lehetőségnek köszön- 
hetően cégük belső hálózatához vagy 
a világhálóhoz hozzáférve az utazás 
ideje alatt is akadálytalanul dol- 


gozhatnak. A hálózati hozzáféréshez 
földi és műholdas csatornákat fognak 
igénybe venni, a lefedettség már a 
szolgáltatás indulásakor is meglehe- 
tősen jó lesz, Észak-Amerika, az Atlan- 
ti-óceán, Európa nagy része, Skandi- 
návia, Oroszország, a Földközi-tenger, 
Kína, India és Japán felett kezdettől 
fogva lehet majd internetezni, a továb- 
bi területek ellátását későbbre tervezik. 
A szolgáltatást vezeték nélküli háló- 
zati kártyával felszerelt készülékekkel 
lehet majd igénybe venni, illetve 
egyes légitársaságok vezetékes ether- 
netkapcsolatot is fognak kínálni. Ára 
repülésenként 25 dollár lesz, az utasok 
lefelé 20 Mbit, felfelé pedig körülbelül 
3 Mbit sávszélességen osztozhatnak. 
Alkalmazási területként természetesen 
nem csak az utasoknak kínált szolgál- 
tatások bővítése vetődhet fel. Ha pél- 
dául fedélzeti internetkamerákat sze- 
relnek fel, akkor géprablás esetén nyo- 
mon lehet követni a gépen történteket. 
Egy további alkalmazás a fedélzeten 
rosszul lévő utasok távoli diagnoszti- 
zálása, amelynek eredménye alapján 
eldönthető, hogy szükség van-e az 
azonnali — költséges — leszállásra, vagy 
a gép folytathatja az útját a célállomás 
felé. További érdekes lehetőségek mu- 
tatkoznak a repülőgépek távoli felü- 
gyelete, a csatlakozó járatokra szóló 
menet közbeni helyfoglalás vagy éppen 
a csomagok kezelése terén. 

2 http:/www.connexionbyboeing.com 


A sokadik védvonal 

A CyberGuard legújabb, PC1I635 jelzé- 
sű tűzfalkártyája már akár a helyi 
hálózaton belülről érkező támadások 
ellen is képes megvédeni használó- 
jának a számítógépét. A PCI foglalatba 
illeszkedő kártya formájában megtes- 
tesülő védelmi eszköz a CyberGuard 
által nemrég felvásárolt SnapGear 
PC630-as jelzésű, hasonló termékének 
a megújított változata. Míg magán a 
kártyán a SnapGear Embedded Linux- 
változat fut, addig a gépen gazda- 
rendszerként Linux, Windows 2000, 
Windows XP vagy Windows Server 
2003 üzemelhet. 

A kártya dinamikus állapotalapú tűz- 
falat húz a gép elé, támogatja a VPN 
protokollokat, betörésérzékelő rend- 
szere a Snortra épül, felügyelete pedig 
webböngészőn keresztül vagy köz- 
ponti kiszolgálóról végezhető el. 

2 http:/www.cyberguard.com 
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Mozgásba lendülünk Ot 3.3 
Megjelent a Mobility nevű, német A Irolltech elkészült a Ot 3.3-as és a 


fejlesztésű forgalomszimulációs OSA (Ot Script for Applications) 1.1-es 
játékprogram 2.0-s változata. A játék változatával. A Irolltech a számozás 
valójában sokkal több annál, mint tekintetében egészen szerényen visel- 
aminek látszik: motorja valós forgalmi kedik, a Ot új szolgáltatásai, a .NEIT- 
keretrendszer, a 64 bites gépek és az 
IPv6 támogatása más gyártóknál ki 
tudja, mekkora változatszám-növeke- 
dést hozna. Újdonság a GNU C--- 
fordító Windows alatti támogatása is; 
ennek köszönhetően a fejlesztők — a 
Ot keretrendszer és a gcc fordító segít- 
ségével — Unix, Linux, Macintosh és 
Windows alapú rendszerekre ugyan- 
azt a környezetet használva készíthet- 
nek alkalmazásokat. 

2 http:/wwwi.trolltech.com 


Mr. Kontrolaltdel 

Szegény David Bradley! Most, hogy 
nyugdíjba vonul, mindenki arról 
beszél, hogy ő írta annak idején 

azt az aprócska programot, amely 

- amikor a felhasználó lenyomta a 
CTRL-HALT- DEL billentyűkombiná- 
ciót — az ÍBM PC-ket újraindulásra 
szólította fel. Pedig az IBM-nél 28 és 
fél évet eltöltő szakembert, aki egyike 
volt a PC-t megalkotó csoport tagjai- 
nak, sok más munkájáért is elismerés 
illetné. Mint egyszer ő maga gúnyo- 
san megjegyezte, neki csak a kód 
megírása jutott, azt , híressé" inkább 
mások tették, amikor elkészítették 

a Microsoft hírhedten megbízhatat- 
lan korai operációs rendszereit. 
Bradley visszavonulását követően 

az Észak-Karolinai Állami Egyetemen 





MÉGJETLTTT 


viselkedést utánoz, ahol a játékos dön- 
tései a valós élethez hasonló módon 
alakítanak ki vagy éppen szüntetnek 
meg például dugókat. A program 
forgalmi modellje a Weimari Bauhaus 


O Kiskapu Kft. Minden Jog fenntartva 


Algoritmusok, wattok 


Egyetem és a DaimlerChrysler kuta- 
tóinak munkája nyomán jött létre. 

A Mobility 2.0 Windows és Linux alá 
tölthető le, kipróbálása 15 napon 
keresztül ingyenes, utána 14 dolláros 
áron vásárolható meg. 

2 http:/www.mobility-online.de 





A lycoris tenyérbe mászik 
A Lycoris bejelentette, hogy ez év 
második negyedévében megjelenik 
tenyérgépekre tervezett operációs 
rendszere. A Desktop/LX Pocket PC 
Edition, röviden 

DL-PPC ígéretük s d 

szerint akár vállalati a 
használatra is alkal- d 

mas, mégis felhasz- "3 
nálóbarát rendszer d 

lesz. Eleinte csak 

ARM processzorokon fog futni, ami 
nem nagy hátrány, hiszen ilyen lapka 
található a Sharp Zaurusban és a HP 
iPag gépekben is. A rendszer normál 

— jelenleg 2.4.18-as számot viselő — 
rendszermagra épül, így más 
géptípusokra is könnyen át lehet majd 
ültetni. A DL-PPC a Windows alapú 
fájl- és nyomtatómegosztásokat is 
képes lesz kezelni, a hálózatot vezeték 
nélküli, USB alapú és infravörös kap- 
csolaton tudja majd elérni. Személyi 
adatkezelő alkalmazása képes lesz 
magát a Lycoris és más gyártók asztali 
operációs rendszereivel összehan- 
golni, illetve az olyan alapprogramok 
sem hiányoznak majd belőle, mint 
egy nagy tudású böngésző, kézírás- 
felismerő vagy médialejátszó. 
2 http:/www.lycoris.com 
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A PowerEscape állítólag az első olyan 
kereskedelmi termékeket mutatta be, 
amelyek az algoritmusok energiafo- 
gyasztás szempontjából történő elem- 
zését teszik 
lehetővé. 

A PowerEscape 
Analyser és a 
PowerEscape 
Cache első- 
sorban algorit- 
musok és számí- 
tógépes rend- 
szerek tervezői számára jelenthet 
nagy segítséget, már amennyiben a 
végtermék áramfogyasztása szempont 
a tervezés során. Segítségével egy-egy 
algoritmus működése többféle memó- 
riakezeléssel és gyorstárszerkezettel is 
elemezhető; meghatározható, hogy 
mely programrészeket lehetne hard- 
veres megoldással gyorsítani; illetve 
felismerhetők azok a pontok, ame- 
lyeknél túl sok adat mozgatása rontja 
a program teljesítményét. Számos 
alkalmazás nagy mennyiségű adatot 
dolgoz fel, ezeknél az energiafogyasz- 
tás akár kilencven százaléka is a 
memória-hozzáférésből fakadhat, 

így a memóriakezelés hatékonyabbá 
tételével és a gyorsítótárbeli találatok 
arányának javításával számottevő 
akkumulátoros üzemidőnövekedés 
érhető el például a hordozható 
eszközöknél. 

A két program jelenleg csak elemzésre 
használható, későbbi kiadásaik vár- 
hatóan már programkód módosításra 
is képesek lesznek. 

2 http:/www.powerescape.com 
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A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
] a barátnőjével tölti, szeret 


autózni és bográcsban főzni. 
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Számos felhasználó 
előtt nem teljesen 
világos, hogy miért 


más rendszergazdaként 2 

vagy különleges ú 
jogosultságokkal nem 
rendelkező 

felhasználóként j 


beállítani egy linuxos 


1 


munkaállomást. 
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A Sanchez Computer Associates bankoknak szánt, Linux 
alapú kulcsfolyamat-rendszere várhatóan legkevesebb ennyi 
százalékkal csökkenti a teljes birtoklási költséget: 50 
Világszerte ennyi millióan használnak Linuxot: 18 

Ennyi a felső árhatára a Commerceguest programjának, 
amely elősegíti, hogy a vállalatok megfeleljenek az új 
Sarbanes-Oxley társasági előírásoknak: 500 000 dollár 


. Az informatikai költségkeretek ennyi százalékát teszi ki 


a belső személyzet fenntartása: /0 


5. A WI-FI-hozzáférésipont-eladások éves növekedési aránya 


2008-ig: 5096 


. Várhatóan ennyi millió WI-Fi hozzáférési pontot adnak majd 


el 2008-ban: 1 


. A WI-Fi-hozzáférésipont-eladások becsült növekedési aránya 


2005-ben: 13299 


. Ennyiedik helyen áll a Linux a WI-Fi hozzáférési pontok 


beágyazott operációs rendszerei között: 1 


. A beágyazott Linux-rendszerrel dolgozó fejlesztők ennyi 


százaléka választotta a saját fejlesztést mint legkedveltebb 
Linux-forrást, illetve -gyártót az elmúlt két évben: 15 


. Ennyiedik helyen állt a saját fejlesztés a beágyazott 


rendszerrel dolgozó fejlesztők legkedveltebb , Linux-forrása, 
illetve -gyártója" listáján az elmúlt két évben: 2 


. A beágyazott Linux-rendszerrel dolgozó fejlesztők ennyi 


százaléka választotta a Red Hatet mint legkedveltebb Linux- 
forrást, illetve -gyártót az elmúlt két évben: 17 


. Ennyiedik helyen állt a Red Hat a beágyazott rendszerrel 


dolgozó fejlesztők legkedveltebb Linux-forrása, illetve 
-gyártója listáján az elmúlt két évben: 1 


. A beágyazott Linux-rendszerrel dolgozó fejlesztők ennyi száza- 


léka választja a , saját fejlesztést" mint legkedveltebb Linux- 
forrást, illetve -gyártót az elkövetkezendő két évben: 18 


. Ennyiedik helyen áll a , saját fejlesztés" a beágyazott 


rendszerrel dolgozó fejlesztők legkedveltebb Linux-forrása, 
illetve -gyártója listáján az elkövetkezendő két évben: 1 


. A beágyazott Linux rendszerrel dolgozó fejlesztők ennyi 


százaléka választja a Red Hatet mint legkedveltebb Linux- 
forrást, illetve -gyártót az elkövetkezendő két évben: 17 


. Ennyiedik helyen áll a Red Hat a beágyazott rendszerrel 


dolgozó fejlesztők legkedveltebb Linux-forrása, illetve 
-gyártója listáján az elkövetkezendő két évben: 2 

A jövőbeni, beágyazott Linuxot alkalmazó programfejlesz- 
tések legkevesebb ennyi százaléka lesz ,képes hozzájárulni 
az alapvetően nem kereskedelmi forrásokhoz": 50 


. Ennyi millió Apache webkiszolgálót vizsgált meg a Netcraft 


2003 novemberében: 30,30 


Források 

1.. Sanchez Computer Associates 
2.. Wired 

3—-6.. Forbes 

7-17: ABI Research, Linux Devices 


los 


Netcraft 
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Számos felhasználó előtt nem 
teljesen világos, hogy miért más 
rendszergazdaként vagy külön- 
leges jogosultságokkal nem ren- 
delkező felhasználóként beállítani 
egy linuxos munkaállomást. Ha 
felhasználóként használjuk a 
rendszert, kétszintű védettséget 
élvezünk. Először Is a rendszer 
megvédi magát, véletlenül nem 
vagyunk képesek ártalmas dolgo- 
kat művelni, például nem tudunk 
rendszerfájlokat, programkönyv- 
tárakat törölni. Másodszor a ren- 
des felhasználó nem futtathat a 
teljes rendszerre hatással lévő 
rosszindulatú programokat. 

Az elterjedt legendával ellen- 
tétben a linuxos rendszerek nem 
teljesen ellenállóak a vírusokkal 
szemben. Sokkal inkább igaz az, 
hogy egy jól beállított rendszer 
jelentős ellenállást tanúsíthat 
velük szemben. A vírusoknak 
rendszerszintű elérési jogosultsá- 
gokra van szükségük ahhoz, hogy 
kifejtsék a hatásukat, például 
írásjogra a hajlékony- vagy merev- 
lemezhez. Mivel a rendes felhasz- 
nálók általában nem rendelkeznek 
ezzel a jogosultsággal, az ilyen 
felhasználó alkalmazása hatékony 
védekezés a vírusok ellen. 
Mindezek ellenére a Linux-fel- 
használóknak Is számolniuk kell 
azzal, hogy a saját fájljaik veszély- 
ben vannak, és ahogyan a linuxos 
csoportmunka-programokban 

is egyre elterjedtebb lesz a kü- 
lönböző programnyelvek hasz- 
nálata (scripting), a veszély egyre 
növekedni fog. A vírusok ellen 

a leghatásosabb védelem mit 
sem változott: ne futtassunk nem 
megbízható vagy ismeretlen 
forrásból származó programot, 
az elektronikus levelekben ér- 
kező programokkal szemben meg 
kiváltképpen legyünk gyanak- 
vóak, hiszen napjainkban ez a 
vírusok elterjedésének a legjel- 
lemzőbb útja. 


Chad Robinson 


Linux Journal 2004, 118. szám 


Rendszermag-fejlesztési hírek 


Bryan OSullivan kifejlesztette a Netplugot, egy 
olyan démont, amely azt figyeli, hogy a hálózati 
kábelek be vannak-e dugva, és azzal jelzi a válaszát, 
hogy felizzítja vagy lekapcsolja a rendszer hálózati 
kapcsolatait. Ez hasznos a laptopok és az olyan 
rendszerek esetében, amelyek sokat vándorolnak 
vagy egy Beowulf, esetleg más alegység tagjal. 

A Netplug a már meglévő, Lennart Poettering és 
mások készítette ifplugd projekthez hasonlóan 
működik. Meglehet, hogy a két projektet a jövőben 
megpróbálják egybeforrasztani. 

A 2.6-os NES egy kissé másképp működik, mint a 
2.4-es, amely a két sorozat közt tényleges össze- 
férhetetlenséget eredményez. A gondot a $define 
NFSEXP. CROSSMNT kifejezés okozza, amely korábban 
egy kissé pontatlan jelentésű volt, és amelyet a 
2.6-test rendszermagban javítottak ki. Ennek vissza- 
változtatása egy pontatlanság visszaállítását jelen- 
tené, úgyhogy minden Jel arra utal, hogy ez tovább- 
ra is gond marad. 

Az összeférhetetlenség akkor jelentkezik, amikor 
egy másik gyártó fejléckódja az affected $define 
sort tartalmazza. Egy egyszerű kanyarral megold- 
ható a kérdéses forráskód hibája. 

Junio C. Hamano felvitte Phillip Lougher SguashE-S 
tömörített fájlrendszerkódját a 2.4-esből a 2.6-test 
fába. A SguashFS tűnik a jelenleg legígéretesebb 
linuxos tömörített fájlrendszernek, bár még mindig 
csak egyszeri írhatóságot ad, és azután csak 
olvasni lehet. 

Nemrégiben a digsig programról írtam: ez egy 
olyan biztonsági modul, amely végrehajtás előtt 
ellenőrzi a bináris állomány ellenőrzőösszegét, így 
biztosítja, hogy az adott rendszeren ne futhasson 
vírusos kód. Nos, úgy tűnik, engem jobban fellel- 
kesített a hír, mint néhány rendszermagfejlesztőt, 
nevezetesen Alexander Víiro-t és Fave/l Machek-et. 
Kiderült — és a digsig fejlesztői is elismerik —, hogy 
a digsig csupán ideiglenes biztonsági módszer, 
amit a parancsfájl-írogató ifjoncok nagyon hamar 
meg tudnának kerülni. Eddig sem vettek a rendszer- 
magba efféle ideiglenes módszereket, mert nem 
nyújtanak biztos megoldást. 

A tavaly november elején kiadott 2.6.0-s rendszer- 
mag próbaváltozatával (2.6.0-test1) egyidőben 4/nus 
Torvalds bejelentette a kód befagyasztását: ez azt 
jelenti, hogy csak azokat a Jjavítófájlokat fogadják el, 
amelyek az adatsérülés, a rendszer összeomlása 
vagy más súlyos hiba kiküszöbölésére szolgálnak. 
Még a kódok rendezettségére irányuló Jjavítófájlokat 
is elutasítják, ha azok nem változtatnak ténylegesen 
a kód működésén. Linus szerint az volt a cél, hogy 
megkezdhessék a hivatalos 2.6.0-s kiadás végső 
előkészületeit, és határozottan utalt arra, hogy a 
kiadás után azonnal átadja a 2.6-os fa karbantartási 
feladatait Andrew Morton-nak. Ez változásnak 
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tekinthető a 2.4-es változathoz képest, amikor 
Marcelo Tosatti csak több kiadás után vette át a fa 
karbantartását. 

Még nem lehet tudni, hogy mikor kezdődik el 

a 2.7-es fa fejlesztése; talán azonnal, amint Andrew 
megkapja a 2.6-os fát, de annál korábban azonban 
biztosan nem. 

Rusty Russell és Tim Hockin együttesen írt egy 
javítófájlt, amely a Linux alatt támogatott csoportok 
számát Jóval kétszáz fölé emeli. A javítófájl valójában 
többezer csoport használatát teszi lehetővé, amire 
időnként sok embernek (például Tim Samba-ügy- 
feleinek) van szüksége. Linus lorvalds úgy találta, 
hogy a javítófájl egyik változata rondább volt, mint 

a másik, de a jelek szerint addig nem zárkózik el a 
magasabb csoportszámúvá tételétől, amíg nem kap 
komolyabb hányingert a megvalósítástól. 

lan Pratt és társai (Computer Laboratory Systems 
Research Group) elkészítették x86-os kiépítésre az 
Xen virtuális számítógép-monitor első üzembiztos 
kiadását, és vendég operációs rendszerként átül- 
tették rá a 2.4.22-es rendszermagot. Az Xen egyet- 
len számítógépen egyidejűleg több operációs rend- 
szert tud futtatni. Amint egy rendszermagot átültet- 
nek az Xenre, a felhasználói bináris fájlok látszólag 
változatlanul futhatnak, vagyis elméletileg bármilyen 
L inux-változat képes futni Xen alatt, mindössze egy 
rendszermag-beültetésre van szükség. Az Xen 
pillanatnyilag nem futtatható rekurzívan, habár sok 
elfajzott rendszermagbetyár érdeklődött ez iránt. 

Eli Billauer megalkotta a /dev/frandom véletlenszám- 
generátort, amely egyes vizsgálatok szerint ötven- 
szer gyorsabb, mint a /dev/urandom. Habár titko- 
sításhoz nem eléggé véletlenszerű (ez egyelőre nem 
is volt cél, de a jövőben talán eléri ezt a szintet), 
azért jól használható tudományos szimuláció céljára, 
algoritmusok terhelési próbájához és kódtörés (data- 
wipes) végrehajtásához. Számos Jó minősítése 
ellenére valószínűleg még jó ideig külső javítófájl 
marad, mivel több rendszermagfejlesztő — köztük 
Nick Piggin — szerint semmi nem indokolja, hogy a 
/dev/frandom a rendszermag területén fusson, teljes 
egészében felhasználói területen is remekül 
végrehajtható. 

2003 október közepén Roman /ppel bejelentette az 
ISCSI szabvány megvalósítását. Noha a megva- 
lósítás nem teljes, és a SysFS helyett az elavult 
/proc fájlrendszert használja illesztőfelületként, bizo- 
nyos mértékig már hasznavehetőnek tűnik. Roman 
megígérte, hogy folytatja a kód karbantartását, ha 
elegendő igény mutatkozik, de ha nem kap segít- 
séget — szavaival élve — ez csak lassan fog menni. 


Zack Brown 
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A Linux Journal 
honlapján számtalan 
gond megoldásához 

találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakor! 
kérdéseket és az egyéb 

útmutatásokat a 

5 www. linuxjournal.com 
honlapon olvashatjátok 
el. A rovatban közzétett 

válaszokat LInux-szak- 
értők kis csapata készí- 
tette el. lovábbi kérdé- 
serteket szívesen fogad- 
Ják (angol nyelven) a 

5 www.Iinuxjournal.com/ 
[7-Issues/techsup.htmi 
címen, ahol csak egy 
kérdőívet kell kitöltene- 
tek, de a btis(ossc.com 
címre levelet is írhattok. 
A levél tárgyában 
szerepeljen a ,BIS" 
kulcsszó. 
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A hónap szakmai tanácsai 


Működő USB-s botkormányt! 


Egy Logitech Wingman Force 3D erő-visszacsatolá- 
sos USB botkormány van a birtokomban. 2.4.20-20.9- 
es rendszermagot használok (Red Hat 9), amelyben 
az USB-támogatás engedélyezve van. Van-e mód 
arra, hogy a botkormányom működjön Linux alatt? 
A Google segítségével találtam néhány lehetséges 
megoldást, de nekem egyik sem működött. 

Pierre Rochefort, prochefortorogers.com 


Az USB botkormányaok jól használhatók Linux alatt. 

A beállítás mikéntjének megismeréséhez érdemes 
elolvasni a Linux USB kézikönyvet a 

2 http:/Avwwv.linux-usb.org oldalon. Ha ennek ellené- 
re is maradnak kérdéseid az USB-támogatás kapcsán, 
a 5 linux-usb-users levelezőlistán fel tudod tenni. 
Greg Kroah-Hartman, gregokroah.com 


Johann Deneux — a 3 http://user.it.uu.se/—johannd/ 
projects/ff/index.shtml címen elérhető weboldala 
szerint — erő-visszacsatolásos meghajtóprogramot 
fejleszt Linuxhoz. A teljes leírás és a letölthető kód 
megtalálható az oldalon, így ki lehet próbálni, hogy a 
te eszközöddel működik-e. Valószínűleg szükség lesz 
némi kódfordítási és modultelepítési tapasztalatra, 
de megéri a tanulást. Kipróbálhatod még a Linux 
Input Drivert (3 http://linuxconsole.sourceforge.net/ 
input/hardware.htm]) vagy a Linux botkormánymeg- 
hajtót (3 http://atrey.karlin.mff.cuni.cz/—vojtech/ 
joystick), amelyek állításuk szerint szintén támogat- 
ják a szóban forgó eszközt. 

Felipe Barousse Boué, fbarrousse(-opiensa.com 


WI-Fi beállítása SuSE-n zárt módra 

sikeresen telepítettem a SuSE 9-et a noteszgépemre, 
egy I hinkPad 600£-re, amelynek van egy Netgear 
MA401 vezeték nélküli kártyája. A SuSE helyesen 
érzékelte a kártyámat, a 128 bites titkosítást bekap- 
csoltam és működik. A gond az, hogy kézzel kell zárt 
módba állítani a kártyát, amikor az elérési ponttal 
(access point) szeretnék kapcsolatot tartani. Minden 
egyes újraindítás után a su paranccsal rendszergaz- 
dai módba kell váltanom és be kell írnom az 
1wconfig wlan0 key xxxxxxxx restricted paran- 
csot, hogy a kártya működjön. A YaS I-tal megfelelően 
beállítottam a kártyát, beleértve a titkosítókulcsot, 

de magától mindig nyílt módban indul el. Kifelejtet- 
tem valamit? Hogyan érhetem el, hogy az iwconfig 
alapértelmezett módja a zárt legyen? 

Kevin Lisciotti, lisciottroyahoo.com 


Készíts egy másolatot a /etc/sysconfig/network/ 
ifcfg.template fájlról és a beállításaidnak megfe- 
lelően módosítsd a benne lévő értékeket. Emellett 
vess egy pillantást a 3 http://portal.suse.com/sdb/ 
en/2002/11/wvavelan.html oldalra, amely részlete- 
sebb tájékoztatást nyújt erről a témáról. 

Felipe Barousse Boué, fbarousse-oplensa.com 
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Red Hat 7.2 és az ethernetkártya 


Mostanában telepítettem a Red Hat /.2-es terjesz- 
tést (ez az első Linux telepítésem), amihez a Linux 
Administration for Beginners (Linux-felügyelet 
kezdőknek) című könyv mellékleteként jutottam 
hozzá. Amikor a rendszert telepítettem, a könyvben 
leírtakkal ellentétben nem kaptam hálózati beállító- 
ablakot. A telepítőnek fel kellett volna ismernie a 
hálózatot, de nem tette. Ezután nem tudtam beál- 
lítani az internetkapcsolatot, ami pedig szükséges 
lenne ahhoz, hogy a súgóoldalakon lévőknél több 
útmutatást kapjak a rendszer tanulásához. 

Egy otthoni PC-t használok a következő összeállítás- 
ban: Intel Pentium III 500 MHz-es processzor, 

256 MB memória, 20 GB WD Caviar IDE merevle- 
mez és Realtek hálózati csatoló (D-Link kártyával 
próbáltam ki). Egy kábelmodemhez csatlakozom 

és nincs helyi hálózatom, bár egy második gép 
rendszerbe állítását is tervezem. 

Úgy néz ki, hogy a Red Hat 7.2 nem ismeri fel az 
eth0-t, bár élő kapcsolat van. Mindenfelé kerestem 
útmutatást. A legtöbben azt tanácsolták, hogy 
hajlékonylemezről telepítsem a Realtek meghajtó- 
programjait, amelyek már a terjesztésben Is megta- 
lálhatók, de mint mondtam, én tényleg új vagyok 
ezen a területen és nincs támpontom. Azon vagyok, 
hogy veszek egy Mandrake-et vagy Red Hat 9-et, 
hátha valamelyiknek használhatóbb telepítője van. 
Marcel, marcelnh4ohotmail.com 


Anélkül, hogy ismernénk a hibaüzeneteket vagy 
látnánk néhány naplófájlt, igen nehéz kitalálni, hogy 
mi is történik a rendszeredben. Rendben van a 
hálózati kártyád? Megfelelően van telepítve? Nincs 
valamilyen összeférhetetlensége egy másik eszköz- 
zel? Eltérő Linux-változat vásárlása helyett inkább 
egy másik hálózati kártyát kellene venni, olyat, amit 
biztosan támogat a Linux. Nézd meg a 

2 http://hardware.redhat.com/hcl oldalt és keress 
olyan kártyát, ami megfelel a pénztárcádnak és a 
rendszerednek. 

Felipe Barousse Boué, fbarousse(opliensa.com 


Az eszközgondok kizárása végett rendszeredet pró- 
báld ki a Knoppixszal (3 http :/Avwvw.knoppix.net), 
ami egy CD-ről futtatható Linux-rendszer. A Knoppixot 
szabadon le lehet tölteni és lemezre lehet sütni. 

Ha a Knoppix futtatásakor a kártya működik, akkor 
már csak idő kell hozzá, hogy némi rendszergazdai 
tapasztalatot gyűjts, ami egy újabb terjesztésre 
történő frissítésnél is jól jöhet. Első Linux-változatként 
próbálj olyat választani, amit a helyi felhasználói 
csoport vagy más általad használt támogatás Ismer. 
Don Martr, dmartkXssc.com 
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NIOS-felület 


A Net Integration lechnologiles 
olyan független számítási hálóza- 
tot kínál, amely a Linuxon alapuló 
Net Integrator Operating 
Systemre (NIOS) épül. Az önjaví- 
tónak és önkarbantartónak terve- 
zett NIOS-felület bárhol kapható 
eszközökre és alkatrészekre épít 
és a kis, illetve közepes méretű 
üzleteket célozza meg. Maga a 
NIOS nyílt forrású programból áll; 
a mérete 16 MB. A NIOS Plat- 
formnak része a Netlntelligence, 
egy mesterségesintelligencia- 
modul, amely független szolgál- 
tatásokat használ rendszerössze- 
tevők és a belső alrendszerek 
létrehozására, telepítésére és 
karbantartására, beleértve tűzfal- 
és DHCP-jellemzőket, valamint a 
DNS-bejegyzéseket. A SystemER 
program a rendszer helyreállítását 
egy végzeteshiba-rendszerössze- 
omlásból két percen belül lehe- 
tővé teszi. Egyéb összetevői közé 
tartozik az Exchangelt! munkacso- 
portos kiszolgáló, a TunnelvVislon 
intelligens VPN-megoldás, amely 
állandó IP-cím nélkül Is működik, 
az Expression Desktop és a 
DoublevVision, ami egy olyan 
redundáns internetkapcsolódási 
módszer, amit arra terveztek, 
hogy több nagy sebességű csa- 
tolót lehessen NIOS-szal meghaj- 
tott kiszolgálókhoz kapcsolni. 

2 http:/Avww.net-itech.com 


Xandros Desktop 2.0 


A Xandros Desktop 2.0-s egy 
könnyen használható grafikus 
környezet, amit mindössze négy 
egérkattintással lehet telepíteni. 
A Debian Sarge-terjesztésre és a 
Xandros bővítéssel ellátott KDE 
3.1.4-re épülő rendszer legfonto- 
sabb tulajdonságai közé tartozik 
a nagyon egyszerű telepítés ön- 
működő lemezrészelosztással, 

a húzd és ejtsd CD-írás a fájlkeze- 
lőn belül, valamint a fájl- és erő- 
forrás-megosztás a Windows-há- 
lózatokkal. A 2.0-s munkaasztal 
kínálatában fellelhető az egy 
ablakon belül fülekkel elkülönített 
webböngészés, valamint a 
felugró ablakok és reklámcsíkok 
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kikapcsolásának lehetősége, egy 
önműködő levészemétszűréssel 
ellátott levelezőügyfél, egy 
beszélgetőügyfél, amely együtt- 
működik az MSN, Yahoo, AOL, 
ICO és IRC-szolgáltatásokkal, 
valamint az OpenOffice.org 1.1. 
A Xandros Desktop 2.0 Standard 
és Deluxe kiadásban jelenik meg, 
a Deluxe változat tartalmazza a 
Crossover Office 2.1-et, egy 350 
oldalas kézikönyvet, extra játé- 
kokat, alkalmazásokat és eszkö- 
zöket, valamint 60 napos, elektro- 
nikus levélben igénybe vehető 
támogatást. 

2 http:/Avww.xandros.com 


TimeStorm Linux Tool Surte 


A TimeSys új TimeStorm Linux 
Tool Suit olyan fejlesztőeszközö- 
ket tartalmaz, amelyek a teljes 
beágyazott-Linux fejlesztési cik- 
lust támogatják, függetlenül attól, 
hogy milyen típusú beágyazott 
operációs rendszert használunk. 
A TimeStorm csomag az Eclipse- 
felületre épül, s vannak eszközei 
a rendszermag-átültetés kezelésé- 
hez, alkatrészek összevonásához 
(hardware integration) és a min- 
denre kiterjedő kipróbálási és 
véglegesítési igényekhez. 

A TimeSys TimeStorm öszevont 
feljesztői környezetének bővítmé- 
nyeként (plugin) szállított Tool 
Sulte minden beágyazott Linux- 
terjesztéssel működik, legyen az 
házilag vagy gyárilag készített. 

A Tool csomag magában foglalja 
a limeStorm Linux Verification 
Sulte-ot, ami egy olyan keretrend- 
szer, amely önműködővé teszi a 
teljes beágyazott terjesztésnek és 
alkalmazásainak a kipróbálását, 
illetve bevizsgálását a fejlesztés 
minden egyes szakaszában. löbb 
mint 1150 nyílt forrású próba áll 
rendelkezésre. A Linux Develop- 
ment Sulte-ban található eszközök 
segítenek a fejlesztőnek egyedi 
Linux-rendszert építeni és átültetni 
azt a céleszközre. A Linux Hard- 
ware-Assisted Debug (hardverrel 
segített hibakeresés) segít a 
hibakeresésben, inicializásában 
és a Linux indításában oly módon, 
hogy kapcsolófelületet biztosít a 


TimeStorm IDE, valamint a JTAG 
és a GDB-t használó, lapkába 
épített hibakeresők között. 

2 http:/Avww.timesys.com 


MontaVista DevRocket 
Development Environment 
A MontaVista DevhRocket 1.0-s 
egy teljesen egybevont (integra- 
ted) grafikus fejlesztői környezet 
beágyazott Linuxhoz. Az Eclipse 
technológián alapuló megoldás 
különböző felületeken, például 
Linuxon, Microsoft Windowson 
és Solarison Is hasonló külsőt és 
felületet nyújt a fejlesztéshez. 

A MontavVista DevRocket a leg- 
újabb Eclipse 2.1-en alapul, 
lehetővé téve a vásárlóknak és az 
internetszolgáltatás-fejlesztőknek 
az Eclipse-felület minden előnyé- 
nek a kiélvezését, belértve az 
Eclipse-közösség által készített 
külső fejlesztéseket, csakúgy, 
mint az Eclipse által támogatott 
eszközök sokaságát. Az egybe- 
vont létfontosságú fejlesztési 
képességek - például a fordítás, 
szerkesztés és hibakeresés mel- 
lett — a DevRock könnyen hasz- 
nálható projektvarázslókat Is 
nyújt, amelyekkel az általános 
beágyazott fejlesztési tennivalókat 
önműködővé lehet tenni. 

2 http:/Avww.mvista.com 


Global Navigator 5.0 


Az NEC Global Navigator 5.0-s 
egyes vagy többszörös kapcsolati 
központok hívásaktivitásának és 
ügynökteljesítményének a megfi- 
gyelésére készült. A Global Navit- 
gator vállalati szintű hívásközpont- 
kezelést, valamint az egy vagy 
több hálózaton elérhető munka- 
hely vezérlését oldja meg. Az al- 
kalmazás az Infocast elnevezésű, 
valós idejű információs programot 
használja, amely a kapcsolati köz- 
pont statisztikáit az ügynök mun- 
kahelyének egy kis ablakába 
küldi. Az új, 5.0-s változat SCO 
UNIX-ról lett átültetve Linuxra és 
MySOL-t használ adatbázis-kezelő 
rendszerként. 

2 http:/Avww.cng.nec.com/cng 
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Linux kontrá $CO 


A rendbontó technológiák elutasítása elhibázott lépés. 





mikor a piacon megjelenik 
egy rendbontó technológia, 
a piac régi Szereplői -— a 


strucchoz hasonlóan smindent meg- 
tesznek azért, hogy ne vegyenek róla 
tudomást. A rendbontó technológiák 
általában vagy erőtlenül indulnak, 
vagy olyan válaszokként, amelyek 
keresik a kérdésüket, így könnyű sem- 
mibe venni, leírni az okoskodó beto- 
lakodókat. Amikor azonban ezeknek 
a módszereknek követői akadnak 

és ostrom alá veszik a területet, a hata- 
lom birtokosai ébredésükkor két vá- 
lasz közül választhatnak: vagy felka- 
rolják a rendbontót, vagy megpróbál- 
ják eltaposni. 

A Linux iskolapéldája a rendbontó 
módszereknek. Programozó-tanoncok 
játékaként, főiskolás feladatként kezdte 
életútját. Az interneten keresztül gyor- 
san elterjedt, de még ekkor is jóval 
elmaradt a hagyományos Unix-rends 
szerek mögött; képességeikorlátokba 
ütköztek, leírásai hiányosak voltak. 

A Linux azért volt rendbontó (és az 
még ma is), mert működik. A nyílt 
forrású fejlesztői modell lassan, de 
biztosan — mint a mesebeli teknőc —, 
könyörtelenül tolta előre a: GNU/Linux 
operációs rendszert éslaz őt kiegészítő 
segédprogramokat, mígnem ezek elér- 
ték, majd elébe vágtak a döbbent, sza- 
badalmákkal felvértezett nyulaknak. 

A Nyilt Forrás Közösségének szellemi- 
sége és a GPL, LGPL, BSD és NLP/MLP 
felhasználási szerződések által nyújtott 
biztosítékok segítenek elkerülni a keres- 
kedelmi Unixokra oly jellemző széthú- 
zást/és jogi alapot nyújtanak a nyílt 
forrású folyamat fejlődéséhez. 

A Linuxot felkaroló és eltaposni pró- 
báló erők között tátongó Szakadék 
széles és mély. Az olyan régóta piac- 
vezető cégek, mint az IBM, a HP vagy 
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az Oracle új üzleti lehetőségeket Sejte- 
nek a Linux-rendszerekben, annak 
ellenére vagy talán pontosat azért, 
mert érdekeltek a kereskedelmi prog: 
ramokban, beleértve a zárt forrású 
UÜnixokat is. Az ellenkező tábordegjes 
lentősebbiképviselője, a Microsoft 
ősrégi Unixégyűlölő, a Linux , termés 
szetes ellensége! — utálja mind nyílt 
származását, mind nyílt forrású fej- 
lesztői modelljét. 

A szegény eltévelyedett SCO valahol 
a szakadék mélyén bolyong. A 5CO 
Group, amely a Linux terjesztésével 
foglalkozó Calderából szülétett újjá, 
most kitagadva érzi magát, mert Ko- 
rábban kereskedelmi Unixot vásárló 
felhasználói tábora Linuxra vált át. 
Az IBM-melsszemben támasztott kö- 
vetelésekbőlés a Linuxéfelhasználók 
fenyegetéséből látszik, hogy a 5CO a 
Caldera korábbi barátságos ölelésének 
erejét a fojtogatásig igyekszik fokozni: 
A lekörözött informatikai cégek régi 
és sajnálatos szokásukhoz híven a 
bírósághoz fordulnak, hogy megpró- 
bálják elérni mindazt, amit a szabad 
piacon nemitüldtak. Ha egy cég jogi 
úttal próbálkozik sikeres üzletpolitika 
helyett, az minden esetben nem várt 
következményekhez vezet. Az, hogy a 
5CO az IBM ALxzeladásokból próbálja 
pótolni az elvesztett piaci részesedése 
miatti bevételkiesést, ahhoz fog vezet- 
ni, hogy az IBMsamiúgytisztésökkenő 
kereskedelmi Unix-eladásai még 
gyérebbé válnak. 

Az, hogy a SCO felhasználási díjakat 
próbál meg kisajtolni a Linux alapú 
kereskedelmi megoldások:szállítóitól 
és a beágyazott Linuxszal Kereskedők- 
től, lehet, hogy rövid távonllelassítja 

a Linux terjedését, de befagyasztja 

a SCO Linuxból remélt bevételeit is. 
Az önkiábrándítás jellemíző válasz a 
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rendbontó módszerekre.A SCO "által 
kiszabott 699 dolláros kereskedelmi és 
32 dolláros beágyazott felhasználási 
díj arról árulkodik, hogy a cég a fel- 
legekben jár. Ez a hercehurca egy 
cseppet sem javít a SCO Unix helyze- 
tén, és nem fogja Darl McBride-ot 
Linuxból származó bevétellel elhal- 
mozni. A SCO áltakelképzelt világban 
ő maga győzedelmeskedik az ÍBM 
elleni perben és a Linux-felhasználási 
szerződések ügyében, de a cég való- 
jában még mindig vesztésre áll. 

A SCO azt képzeli, hogy elfoghatja, 
megsebezheti vagy akár megölheti 

a Linuxot? Ez nem fog megtörténni. 
A feldühödött kereskedelmi és beá- 
gyazott Linuxot használók nem fogsz 
naklegy csapásra SCO Unixot vásás 
rolni, ha az nem nyújt többet a Linux 
nál, még a magas rendelkezésre állású 
rendszerek esetében sem, és beágya- 
zott környezetben teljesen használha- 
tatlan. Az igazán keményvonalasok 
megmaradnak majd a Linuxnál, és 
egy olyan változatot hoznak létre, 
amelyből az összes SCO-maradvány 
kimarad. E lehetőségek közül egyik 
sem segít a SCO-n. McBride-nak és a 
barátainak azt kell megérteniük, hogy 
a SCO-követelései hosszú távon 
ahhoz vezetnek, hogy a SCO-kód 
minden előfordulása - legyen szó akár 
a Linuxban (átmenetileg) található 
kódról, akár az SCO Unixról - érint- 
hetetlenné és eladhatatlanná válik. 
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James Ready 

A MontavVista Software, ME. 
elnöke és ügyvezetője, több 
mint 25 éves mérnöki és 
vállalkozói tapasztalattal bír. 
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A 2.6-os rendszermag új munkasor kezelése 


A rendszerteljesítmény egyik központi kérdése a megszakítási lappangási 
idő. A munkasorok használatával egy meghajtóprogramban kikerülhetjük 
a megszakításoktól védett időigényes kódrészletek használatát. 


legtöbb Unix-rendszerben - így a Linuxban is — 
AA az eszközmeghajtók általában két részre (félre) 

bontják a meghajtók feldolgozását. Az első rész- 
ben (a felső félben) található az ismerős megszakításkezelő, 
amelyet a rendszermag az alkatrésztől kapott megszakítási 
jel észlelésekor hív meg. Sajnos a megszakítás valóban 
méltó a nevére: amikor az alkatrész kiadja a megszakítást, 
az bármilyen futó kódot megszakít. lehát a megszakítás- 
kezelők (a felső felek) aszinkron módon futnak, figye- 
lembe véve a jelenleg futó kódot. Minthogy a megszakí- 
táskezelők megszakítják a futó kódot (legyen az akár más 
rendszermagkód, akár felhasználói folyamat vagy másik 
megszakításkezelő), nagyon fontos, hogy a lehető leggyor- 
sabban fussanak le. 
Még nagyobb baj, hogy néhány megszakításkezelő (Linux 
alatt gyorsak a megszakításkezelők) a futás során kikapcsol- 
ják a megszakításokat a helyi processzoron. Ezt azért teszik, 
hogy a megszakításkezelő megszakítás nélkül, a lehető leg- 
gyorsabban fusson le. Iovábbá az összes megszakításkezelő 
az Összes processzoron kikapcsolja a saját megszakítási 
vonalát. Ez biztosítja, hogy azonos megszakítási vonalnak 
két megszakításkezelője nem futhat egyszerre. Egyúttal 
megakadályozza, hogy a meghajtóprogram készítőjének 
kezelni kelljen a rekurzív megszakításokat, ami bonyolítaná 
a programozást. Ha azonban a megszakítások le vannak 
tiltva, más megszakításkezelők sem tudnak futni. A meg- 
szakításlappangás (interrupt latency) — vagyis hogy mennyi 
időbe telik a rendszermagnak, amíg egy alkatrész megsza- 
kítási kérelmére válaszol — a teljesítmény egyik kulcskérdése. 
Ismétlem, a megszakításkezelők sebessége súlyos kérdés. 
Kisméretű gyors megszakításkezelők írásának az elősegíté- 
sére a második részt, avagy az alsó felet használjuk. Ennek 
a résznek a feladata, hogy a lehető legnagyobb mennyi- 
ségű, későbbre halasztható munkát átvegye a felső résztől. 
Az alsó rész bekapcsolt megszakítások mellett fut, ennek 
megfelelően az alsó fél futtatása nem akadályozza a többi 
megszakításkezelő futását - így nincs is hátrányos hatással 
a megszakítási lappangásra. 
Csaknem minden eszközmeghajtó alkalmaz ilyen vagy 
olyan alsó felet. Az eszközmeghajtó a felső fél (a megszakí- 
táskezelő) segítségével válaszol az alkatrésznek, illetve itt 
végzi el a fontos időérzékeny műveleteket, például az esz- 
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közregiszterek alaphelyzetbe történő állítását vagy az 
eszközből a memóriába történő adatmásolást. A megszakí- 
táskezelő ezután megjelöli az alsó felet, utasítva a rendszer- 
magot, hogy a lehető leghamarabb futassa le a szükséges 
kódot, majd kilép. 

A legtöbb esetben a valódi munka csak ekkor kezdődik 

az alsó félben. Egy későbbi időpontban - gyakorta a meg- 
szakításkezelő visszatérése után azonnal -— a rendszermag 
az alsó felet is végrehajtja. Az alsó fél lefut és elvégzi azokat 
a feladatokat, amelyeket a megszakításkezelő hátrahagyott. 
Az alsó és felső fél közötti munkamegosztás teljes egészé- 
ben az eszközmeghajtó-készítő döntésén múlik. Az eszköz- 
meghajtó-készítők a lehető legtöbb munkát általában meg- 
próbálják az alsó részre hárítani. 

A Linux -— zavaró módon - elég sokfajta módszert ajánl fel 
az alsó rész megvalósítására. Jelenleg a 2.6-os rendszermag 
softirag-k, tasklet-ek és munkasorok (work gueues) 
típusú alsórész-megoldásokkal bír. A korábbi rendszerekben 
másfajta alsó felek voltak elérhetők: például a BH-k és a 
feladatsorok (task gueues interface). Ez a cikk kizárólag az 
új munkasorfelülettel (work gueue) foglalkozik, amely a 
2.5-ös fejlesztői sorozatban mutatkozott be a feladatsorok 
betegeskedő keventd részének a kiváltása végett. 


Bevezetés a munkasorok világába 

A munkasorok két dolog miatt is érdekesek: először is az 
összes alsófél-megoldás közül ezeket a legegyszerűbb 
használni. Másodszor ez az egyetlen olyan alsófél-megol- 
dás, ami folyamatkörnyezetben (process context) is képes 
futni, így a munkasorok jelentik az egyetlen lehetőséget, 
amivel az eszközmeghajtó-készítő akkor élhet, ha az alsó 
résznek aludnia kell. lovábbá a munkasorok képessége 
vadiúj, és szerintem ami új, az király. 

Nézzük meg, mivel is jár az, hogy a munkasorok a folya- 
matkörnyezetben futnak! Ez jelentős különbség más 
alsófél-megoldásokhoz képest, amelyek - ettől eltérő 
módon - megszakítási környezetben futnak. A megszakítási 
környezetben futó kód nem alhat vagy blokkolhat, mint- 
hogy a megszakítási térnek semmilyen újraütemezhető 
háttérfolyamata nincsen. Ezért, mivel a megszakításkezelők 
nincsenek folyamathoz rendelve, az ütemezőnek nincs mit 
alvó állapotba helyeznie, és ami talán még fontosabb: nincs 


mit felébresztenie sem. Következésképpen megszakítás- 
környezetben nem lehet elvégezni olyan műveleteket, 
amelyek a futó környezetet a rendszermagban alvó állapot- 
ba helyeznék. Ilyen művelet a jelző lekapcsolása (downing 
történő másolás, vagy a nem önműködően történő memó- 
riafoglalás. Minthogy a munkasorok folyamatkörnyezetben 
futnak (mint azt látni fogjuk, a rendszermagszálak hajtják 
őket végre), teljes mértékben képesek az alvásra. A rend- 
szermag lényegében pontosan úgy ütemezi az alsó felek 
futását a munkasorokban, mint a rendszer bármely más 
folyamatát. Akárcsak a többi rendszermagszál (kernel 
threads), a munkasorok is alhatnak, meghívhatják az üte- 
mezőt és így tovább. 

Normál esetben a munkasorokat az alapértelmezett rend- 
szermagszálak kezelik. Processzoronként egy ilyen alapér- 
telmezett szál fut. Ezeket events/n alakú névvel jelöljük, 
amelyben n annak a processzornak a száma, amelyhez a 
szál kötődik. Például az egyprocesszoros gépeknek csak 
egy events/0 rendszermagszála lenne, míg a kétprocesz- 
szoros gépeknek már egy events/1 nevű szála is lenne. 
Munkasorainkat azonban akár saját rendszermagszálon is 
futtathatjuk. Amikor az alsó felünk elindul, az alapértel- 
mezett szál helyett a saját egyedi szálunk ébred fel és kezd 
el dolgozni. Egyedi munkasorszálat (unigue work gueue 
thread) készíteni csak néhány teljesítményfüggő esetben 
érdemes. Általában az alapértelmezett szálat használó alsó 
feleket érdemes előnyben részesíteni. Ennek ellenére 
később azt is meg fogjuk nézni, hogy miként lehet munka- 
sorszálat készíteni. 

A munkasorszálak alsó részünket munkasorkezelőnek 
nevezett különleges függvényként hajtják végre — a mun- 
kasorkezelőben készíthetjük el az alsó részünket. A munka- 
sorfelület használata nagyon könnyű; az egyetlen nehéz 
rész magának az alsó résznek (azaz a munkasorkezelőnek) 
az elkészítése. 


A munkasor illesztőfelülete 

A munkasorok használatához először is létre kell hoznunk 
egy munkasorszerkezetet. A munkasorszerkezetet a 
linux/workgueue.h fájlban megadott struct w hork struct 
határozza meg - szerencsére a munkasorszerkezetek 
előállítását két makró könnyíti meg. Amennyiben munka- 
sorszerkezetünket statikusan szeretnénk meghatározni 
(azaz úgynevezett globális változóként), a következő kifeje- 


zéssel közvetlenül megadhatjuk: 
DECLARE WORK (name, function, data) 


Ez a makró létrehozza a struct w hork struct szerkezetet, 
majd a megadott munkasorkezelő és függvény felhasz- 
nálásával alaphelyzetbe állítja. Munkasorkezelőnknek 

a következő prototípusnak kell megfelelnie: 


void my workgueue handler(void "arg) 
Az arg értéket a rendszermag a munkasorkezelő minden 
egyes meghívásakor átadja — ezt a DECLARE WORKOUEUEO 


makróban található data érték határozza meg. Az eszköz- 
meghajtók az érték használatával több munkasort is kezelni 
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tudnak egyetlen munkasorkezelő segítségével. A data érté- 
ket a munkasorok megkülönböztetésére is felhasználhatjuk. 
Amennyiben munkasorszerkezetünket közvetlen módszer 
helyett inkább dinamikusan szeretnénk létrehozni, arra is 
lehetőségünk nyílik. Ha a munkasorszerkezetre csak köz- 
vetett hivatkozásunk van (például azért, mert a kmal locO 
függvénnyel foglaltuk le), a következő módon állíthatjuk 
alaphelyzetbe: 


INIT WORK(p, function, data) 


Ebben az esetben a p a w hork. struct szerkezetre mutat 
majd, a function a munkasorkezelőnk, a data pedig az 

az érték, amit a rendszermag a meghíváskor át fog adni. 

A munkasorszetkezet létrehozását normál esetben csak 
egyszer végezzük el, például a meghajtónk alaphelyzetbe 
állító eljárásában. A rendszermag a munkafolyam-szer- 
kezetet használja a rendszeren futó különféle munkasorok 
nyomon követésére. Érdemes figyelemmel kísérnünk 

a szerkezetet, mert később még szükségünk lesz rá. 


A saját munkasorkezelőnk 

Munkasorkezelőnk lényegében bármit csinálhat, végtére is 
a saját alsó részünkről van szó! Az egyetlen megszorítás, 
hogy kielégítse a megfelelő prototípust. Minthogy munka- 
sorkezelőnk folyamatkörnyezetben fut, szükség esetén 
aludni is tud. 

Megvan a munkasor-adatszerkezetünk és a munkasor- 
kezelőnk, de hogyan tudjuk futtatni? Ha azt szeretnénk, 
hogy az adott munkasorkezelő a legközelebbi, a rend- 
szermag számára is kényelmes helyen fusson le, hívjuk 
meg a következő függvényt és adjuk át neki a munka- 
sorszerkezetünk címét: 


int schedule work(struct work struct "work) 

Ha a besorolás sikeres volt, a függvény nullától eltérő 
értéket ad vissza, hiba esetén azonban nullát. A függvény 
folyamat- vagy megszakításkörnyezetben egyaránt hívható. 
Néha előfordul, hogy a munkasort nem azonnal akarjuk 
beütemezni, csak egy bizonyos idő eltelte után; ilyen 
esetekben a következő utasítást használjuk: 


int schedule delayed work(struct work struct "work, 
unsigned long delay) 


Ilyenkor az adott munkasorszerkezethez rendelt munka- 
sorkezelő a megadott ideig még biztosan nem fog lefutni. 
Például ha van egy my. w hork nevű szerkezetünk és öt 
másodpercre szeretnénk időzíteni, a következő formát 
használjuk: 


schedule delayed work(8my work, 5"HZ) 


Normál esetben munkasorkezelőnket a megszakításkeze- 
lőnkből időzítjük, de semmi sem akadályoz meg bennün- 
ket, hogy ezt most tetszés szerinti helyről tegyük meg. 
Normál esetben az alsó fél és a megszakításkezelő csapat- 
ként együtt dolgozik, közösen oldják meg az eszközzel 


kapcsolatos feladatokat. A megszakításkezelő mint a 
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Munkasor-függvényreferencia 


Statikus munkasorszerkezet-készítés: 
DECLARE WORK(név, függvény, adat) 
Dinamikus munkasorszerkezet: 

INIT WORK(p, függvény, adat) 

Új munkaszál készítése: 


struct workgueue struct 
:create whorkgueue(const char "név) 


Munkaszál törlése: 


void 
destroy workgueue(struct workgueue struct "wg) 


Munka adott munkaszálhoz rendelése: 
int 
gueue whork(struct workgueue struct "wg, 


struct work struct "work) 


Munka ütemezése adott idő eltelte után adott 
munkaszálhoz: 


int 
gueue delayed w ork(struct workgueue struct "wa, 


struct work struct "work, 
unsigned long delay) 


Függőben lévő munkák kivárása az adott munkaszálon: 


void 
flush workgueue(C(struct workgueue struct "wg) 


Munka ütemezése az alapértelmezett munkaszálon: 


int 
schedule w ork(struct work struct "work) 


Munka ütemezése adott idő eltelte után az 
alapértelmezett munkaszálon: 


int 
schedule delayed work(struct work struct "work, 


unsigned long delay) 


Függőben lévő munkák kivárása az alapértelmezett 
szálon: 


void 
flush scheduled work(voi1d) 


Az adott késleltetett munka leállítása: 


int 
cancel delayed work(struct work struct "work) 
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megoldás felső fele általában előkészíti a megmaradt 
munkát, majd beütemezi az alsó felet. Az is elképzelhető, 
hogy a munkasorokat az alsófél-feldolgozáson kívül másra 
szeretnénk használni. 


Munkasorkezelés 

Amikor besorolunk egy munkát, az a munkaszál következő 
ébredésekor fut majd le. Néha előfordul, hogy folytatás 
előtt biztosítanunk kell a munkasor befejeződését a rend- 
szermagban. Ez különösen a modulok esetében fontos, 
amelyeknél a modul kivétele előtt az összes alsó félnek be 
kell fejeződnie. Az igény kielégítésére a rendszermagban 
egy függvényt találunk, amely megvárja, amíg a függőben 


a Lp 


lévő munkaszálon az összes munka lefut: 
void flush scheduled work(void) 


Minthogy ez a függvény a munkaszálon található összes 
függőben lévő munkafolyamatot kivárja, a dolog viszony- 
lag hosszú időt vehet igénybe. Miközben a függvény a 
munkaszálak befejezésére vár, a hívás alszik. Következés- 
képpen ezt a függvényt kizárólag folyamatkörnyezetben 
hívhatjuk meg. Ne használjuk a függvényt, ha ütemezett 
munkánk befejezését nem feltétlenül kell biztosítanunk. 
A függvény nem üríti ki a függőben lévő időzített munká- 
kat. Amennyiben időzítéssel ütemezzük a munkát és az 
időzítés még nem járt le, a munkasor ürítése előtt le kell 


állítanunk az időzítést: 
int cancel delayed work(struct work struct "work) 


Ez a függvény az adott munkasorszerkezethez tartozó 
időzítést állítja le — más munkasorokra nincs hatással. 

A cancel delayed workO függvényt kizárólag folyamat- 
környezetben hívhatjuk meg, mivel alhat. Ha valamilyen 


munkát leállított, nullától eltérő értéket ad vissza, egyéb 
esetben a visszaadott érték nulla. 


Uj munkaszál létrehozása 

Ritkán az alapértelmezett munkasorszál nem elég. Szeren- 
csére a munkasor-csatolófelület lehetővé teszi, hogy saját 
munkaszálat készítsünk és ezt használjuk alsó részünk 
futtatására. Új munkasorszál létrehozására a következő 


függvényt használjuk: 


struct workgueue struct " 
create whorkgueue(C(const char "name) 


A rendszer elindítása előtt (system initialization) a rend- 
szermag például a következőképpen készíti el az alap- 
értelmezett szálakat: 


keventd wg -— create workgueue( "events" ) ; 


Ez a függvény készíti el a processzoronkénti összes mun- 
kaszálat. Visszaadott értéke a struct w horkgueue struct 
szerkezetre hivatkozó mutató, ami a munkasor más mun- 
kasoroktól (például az alapértelmezettektől) való megkü- 
lönböztetésére szolgál. A munkaszál létrehozása után 
hasonlóképpen rendelhetünk hozzá munkákat, mint az 


alapértelmezett munkaszálakhoz: 


int gueue work(struct workgueue struct "wg, 
struct work struct "work) 


Ítt a  wg a create w horkgueueO függvénnyel készített, 

a munkasort azonosító mutató, a w hork pedig a munka- 
sorszerkezetünkre hivatkozó mutató. Másik megoldásként 
a munkát időzítve is ütemezhetjük: 


int 

gueue delayed work(struct workgueue struct "wa, 
struct work struct "work, 
unsigned long delay) 


E függvény működése azonos a gueue whorkO függvé- 
nyével, kivéve, hogy a besorolást a delay kapcsolóban 
megadott pillanatig elhalasztja. A két függvény megfelel 

a schedule w orkO és schedule delayed work) függvé- 
nyeknek, eltekintve attól, hogy az adott munkát az alapér- 
telmezett helyett a megadott munkasorba helyezik el. 
Mindkét függvény siker esetén nullától eltérő értéket, hiba 
esetén pedig nullát ad vissza. Mindkét függvény folyamat- 
vagy megszakításkörnyezetből egyaránt hívható. 

Végül egy adott munkasort a következő utasítással ürít- 
hetünk ki: 


void flush workgueue(struct workgueue struct "wg) 
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A függvény addig vár, amíg wj munkaszálon az összes üte- 
mezett munka be nem fejeződik, és csak azután tér vissza. 


Összegzés 

A munkasor-csatolófelület a 2.5.41-es változattól része 

a rendszermagnak. Akkoriban igen sok meghajtó és alrend- 
szer kezdte el munkahalasztási módszerként használni. 
Felmerül a kérdés: biztos, hogy ez az eszményi alsó rész 
számunkra? Amennyiben az alsó részünket folyamatkör- 
nyezetben kell futtatnunk, valóban a munkasor a megfelelő 
választás. lovábbá ha esetleg rendszermagszálakat szeret- 
nénk létrehozni, valószínűleg úgyszintén a munkasorok 
alkalmazása lesz a legjobb megoldás. De mit tegyünk, ha 
nincs szükségünk olyan alsó részre, ami aludni is tud? Ez 
esetben valószínűleg a tasklet-ek használata a jobb válasz- 
tás. Ezeket is könnyű alkalmazni, de nem használnak rend- 
szermagszálakat. Minthogy nem folyamatkörnyezetben 
futnak, végrehajtásuk során környezetváltási pluszmunka 
sincs — így számunkra is kevesebb többletmunkát okoznak. 


Linux Journal 2003. november, 115. szám 
ET Robert Love (rmIlotech9.net) 
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Niemóriafoglalás a rendszermagban 


Robert Írása röviden bemutatja a rendszermag-memóriafoglalás 
lépéseit, valamint azt Is megtudhatjuk, hogy milyen változások 


történtek a 2.6-os rendszermagban. 


rendszermagfejlesztők bánatára a rendszermag- 
AA ban egyáltalán nem olyan egyszerű memóriát 
foglalni, mint a felhasználói térben. A nehézségek 
több okra vezethetők vissza, többek közt: 
e A rendszermag körülbelül 1 GB virtuális és 
fizikai memóriakorláttal bír. 
e A rendszermemória nem lapozható. 
e A rendszermag fizikailag általában folytonos 
memóriát igényel. 
e A magnak gyakran pihenés nélkül kell 
memóriát foglalnia. 
e A rendszermagban elkövetett hibákért sokkal 
magasabb árat fizetünk, mint bárhol másutt. 





Bár a nagy memóriatömegek elérése nyilvánvalóan nem 
kifejezetten a rendszermagnak kijáró fényűzés, a nehéz- 
ségek tisztázásával sokat tehetünk azért, hogy a folyamat 
viszonylag fájdalommentes legyen. 


Általános célú foglaló (allocator) 
A memóriafoglalás általános célú felülete a rendszermagban 
a kmal locO: 


$finclude clinux/zslab.hsz 
void " kmalloc(size t size, int flag5); 


Ismerősnek tűnhet - végtére is éppen olyan, mint a felhasz- 
nálói térben megszokott mal locO - kivéve, hogy egy má- 
sodik, flags nevű kapcsolót is vár. Most egyelőre tekintsünk 
el tőle és lássuk, mit ismerünk! Először is a méret (size) itt is 
ugyanazt jelenti, mint a mal lo.cO-változatban: a foglalás mé- 
retét adja meg bájtban. Sikeres visszatérés esetén a kmal locO 
a memória size méretű területére ad vissza mutatót. A leg- 
foglalt memória kiosztása bármilyen objektumtípus tárolá- 
sához és eléréséhez megfelelő. Akárcsak a mal locO, a 
kmallocO is lehet sikertelen, ezért ellenőriznünk kell, hogy 
a visszatérési érték nem NULL-e. Lássunk egy példát! 


struct falcon "p; 
p - kmalloc(sizeof (struct falcon), GFP KERNEL); 


11 (1p) 
/: a foglalás sikertelen - itt kezeljük ler/ 
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Zászlók (Flags) 

A flags mező a memóriafoglalás viselkedését befolyá- 
solja. A jelzőbiteket három csoportra bonthatjuk: 
műveletmódosítók, zónamódosítók és típusok. A mű- 
veletmódosító mondja meg a rendszermagnak, hogy 
miképp foglalja le a memóriát. Például ezek mutatják 
meg, hogy a rendszermag pihenhet-e (vagyis a kmal locO 
hívás blokkolhat-e) a foglalás teljesítése közben. Ezzel 
szemben a zónamódosítók arról tájékoztatják a rendszer- 
magot, hogy honnan kell a kérést kielégíteni. Például 
bizonyos kérések teljesítésekor olyan memóriát kell fel- 
használni, amit bármelyik eszköz a közvetlen memória- 
elérés (Direct Memory Access, DMA) szolgáltatáson 
keresztül közvetlenül el tud érni. Végül a típuszászlók 
mutatják a foglalás típusát; ezek a megfelelő zóna- és 








műveletmódosítókat foglalják össze egyetlen szimbólum- 
ban. Általában több zóna és művelet megadása helyett 
egyszerűen csak egy típust adunk meg. 

Az 1. táblázat a műveletmódosítókat sorolja fel, míg a 

2. táblázatban a zónamódosítókat találjuk. Több eltérő 
jelet is használhatunk; a rendszermag memóriafoglalása 
nem egyértelmű. A rendszermagban a memóriafoglalás 
számos jellemzőjét befolyásolhatjuk. Akkor járunk el 
helyesen, ha kódunk a típusjeleket és nem az egyedi 
művelet- és zónamódosítókat használja. A leggyakoribb 
zászlók: a GFP. ATOMIC és a GFP. KERNEL; szinte valameny- 
nyi rendszermag-memóriafoglalás e két zászló közül 
használja valamelyiket. 

A GFP. ATOMIC jel arra utasítja a memóriafoglalót, hogy 
soha ne blokkoljon. Ezt a zászlót olyan helyzetekben 
használjuk, amikor nem szabad , aludni" — azaz atomi 
jellegűnek kell maradni —, például a megszakításkezelők- 
ben, az alsó részben (bottom half) és az olyan folyamat 
jellegű kódokban, amelyek zárakat tartalmaznak. Mint- 
hogy a rendszermag nem blokkolhatja a foglalást és 
megpróbálja felszabadítani a kérelem kielégítéséhez szük- 
séges memóriát, a GFP. ATOMIC zászlót megadó kérelemnek 
kisebb esélye van a sikerre, mint azoknak, amelyek nem 
igénylik ezt a zászlót. Ugyanakkor megoldásunk az 
alvással nem egyeztethető össze, tehát ez az egyetlen 
lehetőség. A GFP ATOMIC használata nagyon egyszerű: 


struct wolf "p; 
p - kmalloc(sizeof (struct wolf), GFP ATOMIC); 


if (Ip) 
/: hiba "/ 


Ennek megfelelően a GFP. KERNEL zászló a normál rend- 
szermagfoglalást jelenti. Ezt a zászlót használjuk az olyan 
folyamatokban, amelyekben nincsenek zárak. Az ilyen 
zászlóval meghívott kmal locO alhat; ezért ezt a zászlót 
csak akkor szabad használnunk, ha nem okoz galibát. 
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A rendszermag szükség esetén az alvás képességét a 
memória felszabadítására használja, ezért aztán az ilyen 
zászlót használó foglalásoknak nagyobb az esélyük a 
sikerre. Amennyiben például nem áll elegendő memória 
rendelkezésre, a rendszermag blokkolhatja a kódot és 

a lemezre menthet néhány nem működő lapot, csökkent- 
heti a memóriagyorstár méretét, kiírhatja a kimeneti 
átmeneti tárat (buffer) és így tovább. 

Néha, például amikor ISA eszközvezérlőt készítünk, biztosí- 
tanunk kell, hogy a lefoglalt memória képes együttmű- 
ködni a kiszolgáló DMA-rendszerrel. Az ISA eszközök ese- 
tében ez a fizikai memória első 16 MB-nyi területét jelenti. 
Ha bizonyosak akarunk lenni benne, hogy a rendszermag 
ebből a területből foglal memóriát, a GFP DMA zászlót kell 
használnunk. Ezt általában a GFP ATOMIC vagy a 

GFP. KERNEL zászlóval együtt használjuk; a jeleket bináris 

OR művelettel kapcsolhatjuk össze. Például, ha a rendszer- 
magot DMA-ra alkalmas memóriaterület foglalására akarjuk 
utasítani és engedélyezzük az alvást, az utasítás a követ- 
kező módon fest: 


char "buf; 


/" DMA-ra alkalmas memóriát szeretnénk és szükség 
ssesetén alhat7"/ 

buf - kmalloc(BUF. LEN, GFP DMA ] GFP KERNEIL ) ; 

if (!buf) 
/: hiba 7/ 


A 3. táblázat a zászlótípusokat sorolja fel, míg a 4. táblázatban 
azt mutatjuk be, hogy az egyes zászlók milyen művelet- és 
zónamódosítóknak felelnek meg. A clinux/gfp.h: fejléc 
azonosítja a zászlókat. 


Memória felszabadítása 

Miután a kmal locO segítségével lefoglalt memória hasz- 
nálatát befejeztük, vissza kell adnunk a rendszermagnak a 
lefoglalt területet. Ezt a feladatot a kfreeO) végzi el, amely 
a felhasználói tér free) könyvtárhívásának felel meg. 

A kfreeO meghatározása így fest: 


$finclude clinux/zslab.hsz 
void kfree(Cconst void "objp); 


A kfreeO használata azonos felhasználó térbeli megfe- 


éa 


lelőjével. legyük fel, hogy p a kmal locO által lefoglalt 
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memóriaterület mutatója. Ebben az esetben a következő 
parancs szabadítaná fel a memóriablokkot: 


kfree(p) ; 


Akárcsak a felhasználói tér freeO) függvénye esetében, 

ha a kfreeO-t egy már korábban felszabadított memóriate- 
rülettel hívjuk meg vagy olyan mutatót adunk át, amely 
nem a kmal locO függvénytől származik, hibázunk, ez 
pedig memóriahibákhoz vezethet. Fontos, hogy kiegyensú- 
lyozottan hívjuk a foglalásokat és a felszabadításokat, 
ügyelve arra, hogy a kfreeO -t mindig pontosan egyszer 
hívjuk meg a megfelelő mutatóhoz. A kfreeO) meghívása 
a NULL értékkel biztonságos, ugyanis az érték létezését 
ellenőrzi — mindazonáltal nem éppen értelmes ötlet. 
Vessünk egy pillantást a teljes foglalásfelszabadítás ciklusra: 


struct sausage "s; 


s - kmalloc(sizeof (struct sausage), GFP. KERNEL ) ; 
if (!s) 

return -ENOMEM; 
E gs AZ 


kfree(s); 


Virtuális memória foglalása 

A kmallocO függvény fizikai és következésképpen vir- 
tuálisan folytonos memóriaterületet ad vissza. Ebben külön- 
bözik a felhasználói tér mal locOs függvényétől, amely 
szintén virtuális, de nem szükségszerűen folytonos fizikai 
memóriaterületet foglal le. A fizikailag folytonos területek 
két elsődleges előnnyel bírnak: először is sok alkatrész nem 
képes virtuális memóriát címezni. Ezért aztán, hogy egy 
memóriaterületet elérhessenek, a memóriablokknak fizikai- 
lag folytonos memóriaterületen kell léteznie. Másodszor a 
fizikailag folytonos memóriablokk egyetlen nagy lapterü- 
letet használ. Ez nagymértékben csökkenti a ILB (transla- 
tion lookaside buffer) memóriacímző munkáját, hiszen 
mindössze egyetlen TLB-bejegyzésre van szükség. 

A fizikailag tolyamatos memóriának akad egy nagy hátránya: 
gyakran igen nehéz fizikailag folytonos memóriaterületet 
találni, s különösen igaz ez a nagyméretű foglalásokra. A csak 
virtuálisan folytonos memória sikeres foglalására jóval na- 
gyobb esélyünk van. Amennyiben nincs szükségünk fizikai- 
lag folytonos memóriára, használjuk a vmal locO) függvényt: 


$finclude clinux/vmalloc.hzs 
void " vmallocC(unsigned long size); 


A vmal1ocO által lefoglalt memóriát a vfreeO) segítségével 
adhatjuk vissza a rendszernek: 


$finclude clinux/vmalloc.hsz 
void vfree(void "addr); 


A vfreeO használata ismét azonos a felhasználói tér 
mallocO és freeO függvényének a használatáéval: 
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struct black bear "p; 


p - vmalloc(sizeof (struct black bear)); 
if (Ip) 
/" hiba "/ 


vfree(p); 


Ebben az esetben a vmal loc) alhat. 

A rendszermagban nagyszámú foglalás használhat 
vmallocO függvényt, mivel csak kevés foglalásnak kell 
egybefüggőnek látszania az eszközök számára. Ha olyan 
memóriát foglalunk le, amit csak programok érnek el, 
például felhasználói folyamatokkal kapcsolatos adatokat 
tárolunk, a memóriának nem szükséges fizikailag folyto- 
nosnak lennie. Ennek ellenére a rendszermagban kevés 
foglalás használja a vmal locO) függvényt. A legtöbb a 
kmallocO-ot választja, mégha szükségtelen is, részben 
történelmi, részben teljesítménynövelési okokból kifolyó- 
lag. Minthogy a fizikailag folytonos lapok jóval kevesebb 
munkát adnak a ILB-nek, az ebből fakadó teljesítménynö- 
vekedést gyakran sokra tartják. Ennek ellenére, ha mega- 
bájtok tucatjait akarjuk lefoglalni a rendszermagban, a 
vmallocO a legjobb választás. 


Apró, állandó méretű verem 
A felhasználói folyamatokkal ellentétben a rendszermagban 
futó kódnak nincsen nagy, dinamikusan növekvő verme 
— ehelyett a rendszermag minden folyamata saját apró, 
állandó méretű veremmel rendelkezik. A verem pontos 
mérete kiépítésfüggő; a legtöbb architektúra két lapot foglal 
le veremnek, a verem tehát a 32 bites gépeken 8 KB. 
Az apró verem miatt kerülendők a nagy, önműködő, 
veremben tárolt foglalások. Ha megnézzük, soha sem 
találunk ilyesmit a rendszermagkódban: 
fdefine BUF LEN 2048 
void rabbit function(void) 
1 

char buf[BUF. LENI ; 

27 ss BI 


A helyes változat a következő: 
2048 


fdefine BUF.LEN 


void rabbit function(voi1d) 


í 
char "buf; 
buf - kmalloc(BUF LEN, GFP. KERNEL ) ; 
if (!buf) 
/" error! 7/ 
76 za 87 
T 


Felhasználói térben ritkán látunk hasonlót, hiszen nincs 

túl sok értelme dinamikusan foglalni memóriát, ha a kód 
írásakor már ismerjük a lefoglalandó méretet. A rendszer- 
magban azonban mindig dinamikus foglalást alkalmazunk, 
amennyiben a foglalás néhány bájtnál nagyobb. Így elke- 
rülhetjük a veremtúlcsordulást, ami egyébként számos 
gondot okozhatna. 


Összegzés 

Fellebbentettük a fátylat a rendszermag memóriakezelé- 
séről, és láthattuk, hogy nem sokkal nehezebb, mint a 
felhasználói térben található megfelelője. Néhány ökölsza- 
bály, amit érdemes betartanunk: 


e —. Döntsük el, hogy alhatunk-e (azaz a kmal locO blokkol- 
ható-e) vagy sem. Ha egy megszakításkezelő közepén 
vagyunk és az alsó részben (bottom half) egy zárat 
tartunk, akkor ezt nem tehetjük meg. Amennyiben 
folyamatszinten vagyunk és nem tartunk zárakat, 
valószínűleg megtehetjük. 

e Ha alhatunk, a GFP. KERNEL-t adjuk meg. 

e . Ha nem, válasszuk a GFP. ATOMIC zászlót. 

e . Amennyiben DMA által használható memóriára van 
szükségünk (például ISA vagy hibás PCI eszközhöz), 
adjuk meg a GFP. DMA zászlót. 

e . Mindig ellenőrizzük és kezeljük a kmal locO) által 
esetleg visszaadott NULL értéket. 
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e — Ne folyassuk el a memóriát; ne felejtsük el akfreeO 
függvényt valahol meghívni. 

e — Biztosítsuk, hogy a kfreeO-t nem hívjuk meg többször, 
és sehol se próbáljuk meg a már felszabadított memó- 
riarészeket elérni. 


Linux Journal 2003. december, 116. szám 


Robert Love (rmlotech9.net) 

Matematika és számítógépes tudományok 
szakos hallgató a Floridai Egyetemen. Amikor 
] éppen nem Linuxot elemez, autóversenyzik, 
Ni! thai ételeket eszik vagy punkzenét hallgat. 


lovábbi adatokat a rendszermagfa fájljaiban találunk: 


e include/linux/gfp.h: a foglalási zászlók gyűjteménye. 


include/linux/slab.h: a kmallocO és társainak 
meghatározásal. 


mm/page alloc.c: lapfoglalási függvények. 


mmislab.c: a kmalloc() és társainak megvalósítása. 
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I12C illesztöprogramok (1. rész) 


Az I2C-busz segítségével figyelemmel követhetjük 
számítógépünk egészségi állapotát. Tekintsük át, hogyan írhatunk 
egy minden szükséges állapotadatot begyűjtő illesztőprogramot! 


Linuxvilág 2003. júniusi és augusztusi számában a 
AA Linux-rendszermag illesztőprogram-modelljével 

foglalkoztam, példaként pedig az I2C alrendszert 
hoztam fel. Írásomban az I2C alrendszer feladataival és a 
hozzá való illesztőprogramok írásával fogok foglalkozni. 
Az I2C egy, két vezetéket használó soros buszprotokoll 
neve, ami eredetileg a Philips fejlesztése. Beágyazott rend- 
szerekben gyakran használják a különféle összetevők 
közötti kapcsolattartásra, a PC-s alaplapok pedig az érzé- 
kelőlapkákkal való párbeszéd céljából alkalmazzák. Az ér- 
zékelők általában a ventilátorok fordulatszámát, a procesz- 
szor hőmérsékletét és más alkatrészek egyéb jellemzőit 
mérik és jelentik. Bizonyos RAM-lapkák is ilyen protokollon 
keresztül továbbítják a DIMM-modullal kapcsolatos ada- 
tokat az operációs rendszernek. 
Az I2C rendszermagkód életének jelentős részét a fő rend- 
szermagfából kimaradva töltötte, fejlesztése egyébként a 
2.0-s rendszermag idején kezdődött. A 2.4-es rendszermag 
már tartalmaz valamennyi I2C-támogatást, elsősorban 
bizonyos megjelenítő-illesztőprogramokhoz. A 2.6-os rend- 
szermaggal az I2C-kód jelentős része bekerült a fő rendszer- 
magfába, azoknak rendszermag-fejlesztőknek köszönhetően, 
akik az adatcsere-felületeket a rendszermag-fejlesztői közös- 
ség számára elfogadhatóbbakká alakították át. Néhány 
illesztőprogram még most is csak a külső CVS-fában talál- 
ható meg, a fő 5 http:/kernel.org fában nem, de csupán idő 
kérdése, hogy ezeknek az átültetése is megtörténjen. 
Az I2C rendszermagkód logikailag több részre bontható, 
amelyek a következők: I2C-mag, I2C buszillesztőprogra- 
mok, I2C algoritmus-illesztőprogramok és I2C lapka-illesz- 
tőprogramok. Írásomban az I2C-mag működésével nem 
foglalkozom, inkább a busz- és az algoritmus-illesztőprog- 
ramok írására összpontosítok. Az I2C lapka-illesztőprogra- 
mok írásának témájára a második részben kerül sor. 


12C buszíllesztóprogramok 

Az ILC buszillesztőprogramok leírása az i2c adapter 

adatszerkezetben található meg, ennek megadása az 

include/linux/i2c.h fájlban szerepel. A buszillesztőprog- 

ramnak csak a következő mezőknek kell értéket adnia: 

e  struct module "owner - értéke (THIS MODULE) segítségé- 
vel a modulra való hivatkozások számlálása oldható meg. 
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e  unsigned int class - az illesztőprogram által 
támogatott I2C osztályeszközök. Értéke általában 
IC ADAP CLASS SMBUS. 

e struct i2c algorithm "algo — mutató az 
i2c algorithm adatszerkezetre, amely az I2C buszve- 
zérlőn folyó adatcsere mikéntjét írja le. Az adatszer- 
kezetről bővebb leírást is fogok adni. 

e char name[I2C NAME SIZEJ - az I2C buszillesztőprog- 
ram beszédes neve. Az itt megadott érték az I2C-csato- 
lóhoz tartozó sysfs fájlnévben jelenik meg. 


Az alábbi kódrészlet — amely az i2c adapter adatszerkezet 
értékadását szemlélteti — egy tiny i2c adap.c nevű I2C- 
csatoló példa-illesztőprogramból származik. Az illesztő- 
program az 57. CD Magazir/I2C könyvtárában található. 


static struct 12c adapter tiny adapter — ( 


. owner  - THIS MODULE, 

.class - I2C ADAP CLASS SMBUS, 
.algo — €tiny algorithm, 

. name — "tiny adapter", 
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Az I2C-csatoló bejegyzését az illesztőprogram az 

i2c add adapter függvény meghívásával végzi el, 
amelynek egy, az i2c adapter adatszerkezetre hivatkozó 
mutatót ad át: 

retval - 12c add adapter(gtiny adapter); 

Ha az I2C-csatoló olyan típusú eszköz felett üzemel, 
amelyhez device adatszerkezet van hozzárendelve 

— ilyenek például a PCI- vagy USB-eszközök -, akkor 

az i2c add adapter meghívása előtt a csatolóeszköz 
szülőjének a mutatóját erre az eszközre kell állítani. 

A drivers/i2c/busses/i2c-piix4.c illesztőprogramban a mutató 
beállítása például a következőképpen történik: 


/: sysfs csatolás beállítása a szülőeszközre 7/ 
piix4 adapter.dev.parent - €dev-sdev; 


Ha a mutató értékét nem adjuk meg, akkor az I2C-csatoló 


7. [iIsta A tiny access függvény 


static s32 tiny access(struct 12c adapter "adap, 
u1l6 addr, 
unsigned short flags, 
char read write, 
u8 command, 
int size, 
union i12c smbus data "data) 
Tt 


int 1, len; 


dev. info(gadap-sdev, "95 hívására a következő 
ss átadott értékekkel " 

"került sor:Mm", 

-— FUNCTION ); 
dev. info(gadap-:sdev, "cím — 9.4xWn", addr); 
dev. info(gadap-:s:dev, "kapcsolók — 96.4xMn" , 

flag5); 
dev. info(gadap-:s:dev, "olvasas iras — JsMn" , 
read write —— I2C SMBUS WRITE ? 


"1ras" "olvasas"); 
dev. info(gadap-:s:dev, "parancs — XdWw" , 
command) ; 


switch (size) ( 
case I2C SMBUS PROC. CALL : 
dev. info(gadap-:dev, 
"méret -— I2C SMBUS PROC CALLMN"); 
break; 
case IZ2C SMBUS GUICK: 
dev. info(gadap-:dev , 
"méret -— I2C SMBUS OUICKMN"); 
break; 
case I2C SMBUS BYTE: 
dev. info(gadap-:dev , 
"méret -— I2C SMBUS BYTEM" ) ; 


a legacy (örökölt) buszra kerül, és a sysfs fában a 
/sys/devices/legacy elérési út alatt látszik. Nézzük, hogy 
mi történik példa-illesztőprogramunkkal bejegyzéskor: 


$ tree /sys/devices/legacy/ 
/sys/devices/legacy/ 
]1-- detach state 
1-- floppyO 
] ]1-- detach state 
] "-- power 
]  -- state 
]-- 12c-0 
] ]1-- detach state 
] ]1-- name 
] "-- power 
]  -- state 
.-- power 
 -- state 


Mint a rendszermag illesztőprogram-modelljével foglalkozó 
korábbi írásokból kiderül, az I2C-csatoló a /sys/class/i2c- 
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break; 
case I2C SMBUS BYTE DATA: 
dev. info(Cgadap-:dev , 
"méret - I2C SMBUS BYTE DATAM" ) ; 
if (read write —— I2C SMBUS WRITE) 
dev. info(gadap-:dev , 
"adat — 9.2xm", data-sbyte); 
break; 
case I2C SMBUS WORD DATA: 
dev. info(Cgadap-:dev , 
"méret - I2C SMBUS WORD. DATAMN") ; 
1if (read write —-— I2C SMBUS WRITE) 
dev. info(gadap-:dev , 
"adat -— 9.4xWn", data-3sword); 
break; 
case I2C SMBUS BLOCK DATA: 
dev. info(Cgadap-:dev , 
"méret -— I2C SMBUS BLOCK DATAMN"); 
1f (read write —— I2C SMBUS WRITE) ( 
dev. info(gadap-sdev, "adat — 96.4XM" , 
data-3word) ; 
len - data-sblock[0]; 
if (len c 0) 
len — 0; 
if (len 5 32) 
lem s 82: 
for (1 —- 1; 1 cz len; 144) 
dev. info(Cgadap-:dev , 
"adat-sblokk[2d] — 9xWn" , 
1, data-sblock[1]); 


J 
break; 
ű 
return 0; 
J 


adapter könyvtárban is megjelenik: 


$ tree /sys/class/12c-adapter/ 
/sys/class/12c-adapter/ 


 -- 12c-0 
]1-- device -5 ../../../devices/legacy/12c-0 
 -- driver -s 


. ./../ . ./bus/i12c/drivers/i12c adapter 


Az I2C-csatoló bejegyzésének törlését az illesztőprogram 
az i2c del adapter függvény - átadott értéke egy, az 

12c adapter adatszerkezetre hivatkozó mutató — meghívá- 
sával végezheti el: 


12c del adapter(gtiny adapter); 


Az 12C alyoritmus-illesztőprogramok 

Az I2C-algoritmust az I2C buszillesztőprogram használja az 
I2C-busszal való kapcsolattartásra. A legtöbb I2C buszillesz- 
tőprogram saját I2C-algoritmust ad meg és használ. Az al- 
goritmus jellege szorosan összefügg a buszillesztőprogram 
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és az adott eszköz közti párbeszéd módjával. Bizonyos I2C 

buszillesztőprogram-osztályokhoz már több I2C algoritmus- 

illesztőprogram is készült; példaként a drivers/i2c/i2c-algo- 
ite.c fájl által kezelt ÍTE csatolókat, a drivers/i2c/i2c-algo- 

ibm ocp.c által vezérelt IBM PPC 405 csatolókat és a 

drivers/i2c/i2c-algo-bit.c fájlban található általános I2C bit- 

eltoló algoritmust említhetném. Mindegyik algoritmus saját 
függvényekkel bír, használatukhoz az I2C buszillesztőprog- 

ram oldaláról külön bejegyzés szükséges. Minderről a 

rendszermagfa drivers/i2c/i2c-algo-".c fájljaiban találhatunk 

bővebb tudnivalókat. 

Példa-illesztőprogramunkhoz saját I2C algoritmus-illesztő- 

programot fogunk készíteni. Az algoritmus-illesztőprogram 

megadása az i2c algorithm adatszerkezetben, az 
include/linux/i2c.h fájlban található. A gyakran használt 
mezők közül íme néhánynak a leírása: 

e "char name[32]; - az algoritmus neve. 

e unsigned int id; — az adatszerkezet által megadott al- 
goritmus típusának a leírása. A különféle típusok meg- 
adása az include/linux/i2c-id.h fájlban található. Az összes 
típus neve az I2C ALGO karakterlánccal kezdődik. 

e int ("master xfer) (struct 12c adapter 
:adap, struct 12c msg msgs[], int num) ; 

— függvénymutató, értéket akkor szükséges neki adni, 
ha az adott algoritmus-illesztőprogram közvetlen I2C- 
elérést is végezhet. Ha az értékét megadjuk, akkor 
mindig ennek a függvénynek a meghívására kerül sor, 
ha egy L2C lapka-illesztőprogram kapcsolatba szeretne 
lépni a lapkával. Ha az értéke NULL, akkor ezt a szerepet 
az smbus. xfer függvény veszi át. 

e int (ssmbus xfer) (struct i2c adapter "adap, u16 

addr, unsigned short flags, char read write, u8 
command, int size, union 
12c smbus data "data); 
-— függvénymutató, akkor kell neki érté- 
ket adni, amikor az algoritmus-illesztő- 
program hozzáférhet az SMB-buszhoz. 
A legtöbb PCI alapú I2C-buszillesztő- 


static struct 12c algorithm tiny algorithm -— ( 


. name — "tiny algorithm", 
.1d — I2C ALGO SMBUS, 

. Smbus. xfer — tiny access, 

. functionality — tiny func, 


ja 


A tiny func függvény egészen kisméretű, a feladata mind- 
össze az, hogy az I2C-magot tájékoztassa az algoritmus által 
támogatott I2C üzenettípusokról. Ettől az illesztőprogram- 
tól az alábbi néhány I2C üzenettípus támogatását várjuk el: 


static u32 tiny func(struct 12c adapter "adapter) 
í 
return I2C FUNC SMBUS OUICK I 
I2C FUNC SMBUS. BYTE I 
I2C FUNC SMBUS. BYTE DATA I] 
I2C FUNC SMBUS. WORD. DATA ] 
I2C FUNC SMBUS BLOCK DATA; 


Az összes I2C üzenettípus az include/linux/i2c.h fájlban van 
megadva, és az I2C FUNC karakterlánccal kezdődik. 

A tiny. access függvény meghívására akkor kerül sor, 
amikor egy I2C ügyfél-illesztőprogram az IÍ2C-busszal 
szeretne párbeszédet kezdeményezni. Példafüggvényünk 
meglehetősen egyszerű: mindössze naplózza az I2C lapka- 
illesztőprogram kéréseit a sys 109-ba, valamint a hívó felé 
jelenti a sikeres végrehajtást. A napló alapján minden 
különböző cím- és adattípus összesíthető, amelyet egy I2C 
lapka-illesztőprogram valaha is igényelhet. A példafügg- 
vény megvalósítása az 1. listán látható. 


2. lista Az ,m75" I2C ügyfélillesztőprogram 


$ modprobe 1m75 
$ tree /sys/bus/i2c/ 


program képes erre, tehát esetükben /sys/bus/i2c/ 

ennek a függvénymutatónak értéket ]1-- devices 

kell adnunk. Ha ezt megtesszük, akkor ] ]1-- 0-0048 -s ../../../devices/legacy/i2c-0/0-0048 

mindig ennek a függvénynek a meghí- [EE 0-0049 5 ../../../devices/legacy/i12c-0/0-0049 

vására kerül sor, amennyiben egy I2C ]1-- 0-004a -5 ../../../devices/legacy/12c-0/0-004a 

lapka-illesztőprogram kapcsolatba ]1-- 0-004b -s5 ../../../devices/legacy/12c-0/0-004b 

szeretne lépni a lapkával. Ha az értéke 1-- 0-004€c -s ../../../devices/legacy/i2c-0/0-004c 

NULL, akkor ezt a szerepet a Iz 0 0049 25. ./ / 7deévicés/legacy/12c 0/70-004d 

master xfer függvény veszi át. [-- 0-004e -s ..7..7../devices/legacy/12c-0/0-004e 
e uUu32 (Gfunctionality) (struct ] "-- 0-004f -s5 ../../../devices/legacy/12c-0/0-004f 

12c adapter "); "-- drivers 

— függvénymutató, a megadott ]-- i2c adapter 

függvényt az I2C-mag hívja meg annak 5" "im 

meghatározásához, hogy az I2C-csatoló ]1-- 0-0048 -5 ../../../../devices/legacy/i2c-0/0-0048 

illesztőprogram milyen jellegű írásokra 1-- 0-0049 -s ../../..7.-/devices/legacy/i2c-0/0-0049 

és olvasásokra képes. I1-- 0-004a -s ../../../../devices/legacy/i2c-0/0-004a 

]1-- 0-004b -s ../../../../devices/legacy/12c-0/0-004b 

Az I2C-csatoló példa-illesztőprogramunk- 1-- 0-004c -s ../../../../devices/legacy/i2c-0/0-004c 
ban az i2c adapter adatszerkezet a ]-- 0-004d -s ../../../../devices/legacy/12c-0/0-004d 
tiny algorithm változóra hivatkozott. ]-- 0-004e -s ../../../../devices/legacy/i12c-0/0-004e 
Ennek az adatszerkezetnek a megadása "-- 0-004f -s ../../..7/../devices/legacy/i2c-0/0-004f 


a következő: 
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Elkészült a tiny. i2c adap illesztőprogram, lefordítottuk, 
betöltöttük — de mire jó? A válasz prózai lesz: önmagában 
semmire. Az I2C buszillesztőprogramnak I2C ügyfél-illesz- 
tőprogramra van szüksége ahhoz, hogy bármi értelmeset 
tudjon tenni, azon kívül, hogy elücsörög a sysfs fában. 

Az 1m75 I2C ügyfél-illesztőprogram betöltéskor tehát a 
tiny i2c adap illesztőprogram segítségével próbálja meg- 
találni azt a lapkát, amelyhez őt írták (lásd a 2. listát). 
Mivela tiny i2c adap illesztőprogram minden olvasási és 
írási kérésre sikert jelezve válaszol, az A tiny access függ- 
vény 1m75 I2C lapka-illesztőprogram azt hiszi, hogy az 1m75 
lapka lehetséges elérési címeinek mindegyikén talált egy 
ilyen lapkát. A bőséges címválaszték az oka annak, hogy a 
0-0048 — 0-004f£ tartományban több I2C-eszköz is létrejött. 
Ha benézünk valamelyik eszköz könyvtárába, akkor a 
lapka-illesztőprogram érzékelőfájljait láthatjuk: 


$ tree /sys/devices/legacy/12c-0/0-0048/ 
/sys/devices/legacy/12c-0/0-0048/ 

]1-- detach state 

]-- name 

][-- power 

]  -- state 

]1-- temp input 

]-- temp max 

 -- temp min 


A detach state fájlt és apower könyvtárat a rendszermag- 
illesztőprogram magja hozza létre, mindkettő az energia- 
kezelésben jut szerephez. Ismétlem, ezeket nem az 1m75 
illesztőprogram hívja életre. lekintsük át a könyvtár további 
állományainak a feladatát! 

Ha az 1m75 illesztőprogramból lekérdezzük a temp. max 
pillanatnyi értékét, a következőt kapjuk: 


$ cat /sys/devices/legacy/12c-0/0-0048/temp. max 
1000 


Az érték lekérdezéséhez az 1m75 illesztőprogram az I2C-busz 
bizonyos címeiről végzett olvasásra kérte a tiny i2c adap 
illesztőprogramot. A kérést a sys 10og alapján lehet követni 
(lásd a 3. listát az 57. CD Magazir/IRC könyvtárában). 

A napló alapján kiderül, hogy a tiny. access függvény 
meghívása három alkalommal történt meg. Az első parancs 
egy w ord típusú adatot akart kiolvasni a 0048-as című 
eszköz 0 számú regiszteréből. A második és a harmadik 
olvasás ugyanezen eszköz 3-as és 2-es regiszterére irányult. 
A parancsok a drivers/i2c/chips/lm75.c fájlban található 

1m75 update client függvény kódjának a következő 
részeivel társíthatók: 


data-stemp. input -—- 1]m75 read valueCcilient, 
LM75. REG TEMP); 
data-s5temp max - 1]m75 read valueCcilient, 
LM75 REG TEMP. OS); 
data-stemp hyst - 1]m75 read valueCcilient, 
LM75. REG TEMP. HYST); 


Ugyanezen fájl lm75 read valu"e függvénye az alábbi 
kódot tartalmazza: 
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/" Minden regiszter w hord méretű, kivéve a 

beállítóregisztert. Az LM75 a felsőbb helyi értékű 

bájtot helyezi előre, pontosan fordítva ahhoz 

képest, ahogy azt megszoktuk. "/ 

static int 1m75 read value(struct i2c client 
client, u8 reg) 


1f (reg -- LM75 REG CONF) 
return 12c smbus read byte data(Cclient, 
reg) ; 
else 
return swap. bytes( 
12c smbus read word data(client, 
reg) ); 


Amikor tehát az 1m75 illesztőprogram ki akarja olvasni a leg- 
nagyobb hőmérsékleti értéket, a regiszter számával meghívja 
az 1m75 read value függvényt, amely viszont az I2C-mag 
i2c smbus read word data függvényének adja át a szót. Az 
I2C-magnak ez a függvénye megkeresi, hogy az ügyféleszköz 
melyik I2C-buszon található, majd az átvitel végrehajtása 
érdekében az ehhez az I2C-buszhoz társított algoritmust hívja 
meg. A tiny. i2c adap illesztőprogramunk tehát ezzel a mód- 
szerrel kapja meg az átvitel elvégzésére vonatkozó kérést. 
Ha ugyanebbe a sysfs fájlba írni szeretnénk, az 1m75 illesztő- 
program ugyanilyen eljárással kéri meg a tiny. i2c adap 
illesztőprogramot az I2C-busz megadott címére végzendő 
adatírásra. A sys109-ban a kérés adatai is megjelennek: 


$ echo 300 5 /sys/devices/legacy/12c-0/ 

53 0-0048/temp. max 

$ dmesg 

12c adapter 12c-O: tiny access hívására 

sa következő átadott értékekkel került sor: 
12c adapter 12c-O: cím - 0048 

12c adapter 12c-O: kapcsolók - 0000 

12c adapter 12c-O: olvasas iras -— iras 

12c adapter 12c-O: parancs — 3 

12c adapter 12c-O: méret - I2C SMBUS WORD DATA 
12c adapter 12c-O: adat - 8000 


Összegzés 

Ez alkalommal összefoglaltuk az I2C illesztőprogram-alrend- 
szer alapvető jellemzőit, valamint áttekintettük, hogyan lehet 
egyszerű I2C busz- és I2C algoritmus-illesztőprogramot írni, 
amely bármely meglévő I2C ügyfél-illesztőprogrammal 
együttműködik. A teljes illesztőprogram dmn-09-i2c-adap.c 
néven az 57. CD Magazir/I2C könyvtárában található. 

Az I2C lapkaillesztőprogramok írásának témájával a második 
részben foglalkozunk. 


Linux Journal 2003. december, 116. szám 


Greg Kroah-Hartman (gregcokroah.com) 

Jelenleg a Linux-rendszerek USB és gyors csatla- 
koztatású (PCI Hot Plug) egységei rendszermagba 
épített meghajtóprogramjainak a fejlesztője. 

Az IBM-nél dolgozik és rendszermaggal kapcso- 
latos kérdésekkel foglalkozik. 
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A dcache méretezése RCU-alapokon 


A Linux fájlnévkeresési rendszerének újraszervezése sokat számíthat 


a komolyabb kiszolgálók méretezésekor. 


emrég jelent meg 2.6-os Linux-rendszermagban 
az általában olvasott adatszerkezetekre kiélezett 
összehangolási módszer, az RCU (read-copy 
update, azaz olvasás-másolás-frissítés). Ebben a cikkben 
azt mutatjuk be, miképpen segíti az RCU a Linux könyv- 
tárbejegyzés-gyorstárának (dcache) a méretezhetőségét. 
Ha a dolgok hátterére is kíváncsiak vagyunk, olvassuk el 
a , Using RCU in the Linux 2.5 Kernel" című írást a Linux 
Journal 2003. októberi számában. 





Linux könyvtárbejegyzés-gyorstár 

A Linux dcache a fájlrendszer hierarchiájának egy részét a 
memóriában kezeli. Ez a másolat költséges lemezműveletek 
nélkül is lehetővé teszi az útvonalkereséseket, amellyel 
nagymértékben növeli a fájlműveletek hatékonyságát. 

A Linux-rendszermag a mount és umount műveletek meg- 
könnyítése érdekében a befűzési fáról (mount tree) is tárol 
egy másolatot struct vfsmount szerkezetekben. 

De ha a Linux 2.4 dcache ilyen nagyszerű, akkor miért kell 
megváltoztatni? A 2.4-es dcache nagy gondja, hogy globális 
dcache lock zárat használ. Ez a zár kis rendszereken 
gyorstárvonalon fürgeséget, nagy rendszereken azonban 

a méretezhetőség komoly gátját jelenti, mint azt a képen is 
megfigyelhetjük. 


A deache szemléletes bemutatása 

Ebben a részben a cikkben később előforduló RCU-vonat- 
kozású dcache-változásokkal ismerkedhetünk meg. A to- 
vábbi részletekre kíváncsi olvasóinknak a forráskód átbön- 
gészését javasoljuk. 

Írásunkban a 1. ábrán bemutatott fájlrendszert fogjuk 
példaként felhasználni, amelyen két, r1 és r2 gyökérrel bíró 
befűzött fájlrendszert találunk. Mint azt a szaggatott nyíl 
mutatja, a második fájlrendszert a b könyvtár alá fűztük be. 
A g nevű állományt mostanában nem értük el, ezért nem is 
szerepel a dcache-ben - ezt szaggatott kék kerettel jelöltük. 
A dcache" alrendszer a fájlrendszerfa több nézetét is kezelni 
tudja egyszerre. A 2. ábra a könyvtárszerkezet megjelenítését 
mutatja be — minden egyes dentry egy-egy könyvtárnak 
felel meg, amely kétszeresen befűzött, d subdirs mezővel 
kezdődő, körkörös listát tárol. Ez a lista fut végig a gyermek 
dentry-bejegyzések d. chi Id mezőin. Minden gyermek 

d parent mutatója értelemszerűen a szülőjére mutat. A be- 
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fűzési pont 
(dentry b) nem 
közvetlenül 

a befűzött fájlrend- 
szerre hivatkozik; 
ehelyett a befűzési 
hely d mounted 
kapcsolóját állítjuk 
be, majd a dcache 
kikeresi a befűzött 
fájlrendszert a 
mount hashtable 
táblázatából. Ezt a 
folyamatot a későbbiek folyamán ismertetjük. 

Bár a d subdirs listákat közvetlenül is kereshetnénk, nagy 
könyvtárak esetében ez meglehetősen lassú megoldás 
lenne. Ezértaz d lookupO inkább egy hasítótáblát készít 
a könyvtárak dentry mutatóihoz és a gyermekek nevéhez. 
Ezt a dentry hashtable-t használja fel a megfelelő dentry- 
bejegyzéshez. A táblát a 3. ábra mutatja be a dentry unused 
elemmel kezdődő LRU listával együtt. 

Az LRU lista minden dentry eleme általában a hasítótáb- 
lában (hash table) is benne van; kivételt képeznek azok az 
esetek, amelyekben a szülőkönyvtárak ideiglenesek, ilyen 
például az NES és a hozzá hasonló osztott fájlrendszerek. 
Minden dentry a d inode mutató segítségével hivatkozik 

a hozzá tartozó fájlleíróra (inode). A d inode mutató negatív 
dentry-bejegyzéseknél lehet NULL is, ami a hiányzó 


1. ábra Fájlrendszerfa-példa 





2. ábra Fájlrendszerfa-példánk 
dcache-megvalósítása 


fájlleíróra utal. Negatív dentry jöhet létre például akkor, 
amikor a fájlrendszer törli a dentry fájlját, vagy ha valaki 
zárolni próbál egy nemlétező állományt. A negatív dentry 
elemek felgyorsíthatják a rendszer teljesítményét, hiszen így 
a nemlétező fájlok ismételt elérési kísérlete során nem kell 
folyton az alsóbb szintű fájlrendszerhez fordulni. Ehhez 
hasonló módon a közvetlen befűzések is azonos dentry- 
bejegyzéseken osztozkodnak, mint azt az 4. ábrán láthatjuk. 
A 5. ábrán egy magas szintű dentry állapotdiagramot 
láthatunk. A normál dentry életciklus a következő: 


1. Ad allocO lefoglalja az új dentry-t az újonnan hivat- 
kozott állományhoz, ezzel belépünk a New (új) állapotba. 

2. Ad addO nevet és fájlleírót rendel az új bejegyzéshez, 
ezzel beléptünk a Hashed állapotba. 

3. Miután végzett a fájllal, ad. putO felveszi a dentry-t 
a LRU listába és beállítja a DCACHE. REFERENCED bitet 
ad vfs flags mezőben - így jutunk el az LRU Ref 
(Hashed) állapotba. 

4. Amennyiben az állományra az LRU Ref (Hashed) 
állapotban ismét hivatkoznak, a dget locked - ame- 
lyet általábana d lookupO hív meg - használatra jelöli 
ki. Ha a következő prune dcacheO híváskor még 
mindig használatban van, eltávolítódik az LRU listáról 
és ismét visszakerül a Hashed állapotba. 

5. Egyébként a prune dcacheC eltávolítja a 
DCACHE. REFERENCED bitet ad vfs flags mezőből, 
és ilyen módon eljutunk az LRLI (Hashed) állapotba. 

6. Akárcsak az előbbi esetben, ha a fájlra ismét hivatkoz- 
nak, a dget lockedO használatra jelöli be, hogy azután 
a prune dcache() eltávolíthassa a LRU listáról és ismét 
Hashed állapotba kerüljön át. 
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4. ábra 
Közvetlen befűzésű álnévláncok 


5. ábra A dentry állapotdiagram 


7. Egyébként a második egymást követő prune dcacheO 
hívás után a d free) függvényt hívjuk meg a 
prune. one dentryO függvényen keresztül, és végül 
Dead (halott) állapotba kerül. 


A 6. ábrából kiolvasható egyéb útvonalak is elképzelhetőek. 
Például amikor egy osztott fájlrendszer gyorstárazott fájl- 
mutatót alakít új dentry-bejegyzéssé, az. alloc anonO 
függvény segítsé- 
gével lefoglal egy 
dentry-t, miköz- 
ben az objektum 
szülője e dentry 
gyorstárban már 
nem is létezik. 
Hasonlóképpen, 
amikor a 

d deleteŐ segít- 
ségével kitöröljük 
az adott dentry 
alatti állományt 
vagy könyvtárat, 
a dentry-t Negatív 
állapotba helyez- 
zük. Ez a következő lépésben halott (Dead) állapotba jut. 

A 6. ábra a mount hashtable adatszerkezetet mutatja be, 
amelyet a befűzési pont dentry és a befűzött fájlrendszer 
struct vfsmount szerkezetének összerendelésére haszná- 
lunk fel. Ez az összerendelés a mutatókat és a befűzési pont 
dentry-ket, valamint a mutatót és a befűzési pontot tartal- 
mazó fájlrendszer struct vfsmount szerkezetét szervezi 
(pontosabban hasheli) össze. A dentry mutató és a struct 


mount haszshtable 


6. ábra Befűzési pontok átvitele 
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7. lista Zárnélküli útvonal-név-szakasz-keresés 


struct dentry " 
- d lookup(struct dentry " parent, 
struct gstr " name) 


unsigned int len - name-:len; 
unsigned int hash - name-:hash; 
const unsigned char "str - name-sname; 
struct hlist head "head - 
d hash(parent, hash) ; 
9 struct dentry "found -— NULL; 
10 struct hlist node "node; 
JT 
12 rcu read lockO; 
13 hlist for each (node, head) ( 


1 
2 
3 
Hi 
5 
6 
7 
8 


14 struct dentry "dentry; 

T5 unsigned long move. count; 

16 struct gstr " gstr; 

aZ 

18 smp.read barrier dependsO ; 

19 dentry - hlist entry(node, struct dentry, 
20 d hash); 

21 if (unlikely(dentry-sd bucket !- head)) 
22 break; 

23 move. count - dentry-:sd move. count; 

24 smp.rmbO ; 

25 if (dentry-:sd name.hash !- hash) 

26 continue; 

27 if (dentry-sd parent !- parent) 

28 continue; 

29 astr - dentry-sd gstr; 


vísmount ilyen 
formán történő 
összekapcsolása 
lehetővé teszi, 
hogy egy kicsit 
elegánsabban 
kezeljük az 
azonos befűzési 
ponthoz rendelt 
befűzéseket. 

A 2. ábrán bemu- 
tatott példafájl- 
rendszer a 7. ábrán 
bemutatott 
struct vfsmount 
szerkezetet ered- 
ményezné. A vfs1 
szerkezetben az mmt mountpoint és az mnt. root helyen 
egyarán az r1 gyökér dentry-t találjuk, mivel ez lesz egy- 
ben a fájlrendszer legvégső gyökere is. A vfs2 szerkezetben 
a b dentry mmt mountpoint hivatkozásként szerepel, az 

r2 pedig mint a hozzá tartozó mnt. root. Így amikor a 
mount. hashtable keresés visszaadja a vfs2-höz tartozó 
mutatót, az mit root mező alapján gyorsan beazonosíthat- 
juk a befűzött fájlrendszer gyökerét. A befűzött 
fájlrendszerek teljes alakja az mnt mount/mnt child 
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30 smp. read barrier dependsO ; 
31 1f (parent-sd op ég 
32 parent-:d op-:d compare) í 
33 1f (parent-sd op-:d compare(parent, astr, 
34 name) ) 
35 continue; 
36 j else ( 
37 if (astr-slen !1- len) 
38 continue; 
39 1f (memcmp(gstr-sname, str, len)) 
40 continue; 
41 3 
42 spin lock(gdentry-sd lock); 
43 7 
44 : Ha a dentryt áthelyezték, 
ssa keresés sikertelen 
45 37 
46 if (]Iikely(move count -—- 
47 dentry-3d move. count)) (1 
48 if (!d unhashed(dentry)) ( 
49 atomic inc(gdentry-sd count); 
50 found - dentry; 
51 3 
52 3 
53 spin unlock(gdentry-sd lock); 
54 break; 
55 3 


56 rcu. read unlockO; 
57 return found; 
58 3 


listákból látható. Ezeket a listákat a copy tree) és néhány 
további függvény használja, miközben visszacsatolt befű- 
zést készít (lbopback mount), amelyhez a teljes útvonal- 
névtér adott alfájában befűzött, valamennyi fájlrendszer 
áttekintése szükséges. 


ARCÚ alkalmazása a dcache-en 

A dcache teljes párhuzamosítása meglehetősen összetett 
feladat volna, és úgy gondolták, hogy túlságosan kockáza- 
tos lenne beletenni a 2.5 változatba. A 2.6-os dcache mind- 
össze az első lépést tette meg az RCU útján; a 2.7-es fela- 
data lesz bármiféle zár foglalása nélkül a teljes utat bejárni. 
Az útvonalszakasz-kereséseket az 1. listában bemutatott 

.— d lookup() függvény végzi. Az d lookupO függvényt 
a szülőkönyvtár dentry-bejegyzését jelölő mutatóval és a 
keresendő névvel kell meghívni. A nevet gstr szerkezetben 
adjuk át, amelyben a karaktersorozatot megadó mutatót, 

a szöveg hosszát, a dcache hasítótáblához használható 
előfeldolgozott hasítóértéket, valamint — amennyiben 
szükséges — magát a nevet találjuk. 

Az 5-7. sor a struct gstr szerkezetet értelmezi. A 8. sor 


Esz át a 





általános dcache hasítótáblához, kinyerve belőle a megfe- 
lelő hasítólánchoz tartozó mutatót. 

A 12. és 56. sor jelöli a kód RCU-védett szakaszait, kikap- 
csolva az időosztást (preemptive) a CONFIG PREEMPT 


2. lista Utvonal-név-szakaszkeresés és -átnevezés 
versenyhelyzetének feloldása 


1 struct dentry "7 
2 d lookup(struct dentry 7" parent, 


3 struct gstr "7" name) 

4 í 

5 struct dentry " dentry -— NULL; 

6 unsigned long seg; 

7 

8 do ( 

9 seg - read segbegin(grename lock); 
10 dentry - . d lookup(parent, name); 
Lal if (dentry) 

12 break; 


13 ll while (read segretry(£rename lock, seg)); 
14 return dentry; 


3. lista A dentry-szerkezetek késleltetett felszabadítása 


1 static void d free(struct dentry "dentry) 
2 1 
3 if (dentry-sd op 88 dentry-:sd op-:d release) 
4 dentry-s5d op-:d release(dentry) ; 
5 call rcu(gdentry-sd rcu, d callback, 
— dentry); 
6? 


4. lista A dentry-bejegyzésekhez tartozó RCU callback 
függvény 


1 static void d callback(void "7arg) 

2 

3 — struct dentry " dentry - (struct dentry 
9 "Jarg; 


if (dname external(dentry)) ( 
kfree(dentry-s5d astr); 
J 


kmem. cache free(dentry cache, dentry); 
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rendszermagokban, csakúgy, mint a Linux Journal 2003. 
októberi számában olvasható , Using RCU in the Linux 2.5 
Kernel" cikkben bemutatott Reader-Writer-Lock/RCU 
esetében. A 13—55. sor a kiválasztott hasítólánc elemein 
lépked végig megfelelő dentry után kutatva. A 18. sor egy, 
csak a DEC Alpha gépeken lényeges memóriakorlát keze- 
lését végzi. Egyéb processzorokon a mutató visszakódolása 
által létrehozott adatfüggőség önmagában elegendő, így 
ezeken a processzorokon a 18. sor nem készít kódot. 
Minthogy ez a keresés nem kér zárat, versenyhelyzetbe 
kerülhet a rename (átevezés) rendszerhívással. Egy ilyen 


www.linuxvilag.hu 


rendszerhívás a dentry-t egy másik hasítóláncba mozgat- 
hatja át, magával rántva az egész keresést. A 21. és 22. sor 
az ilyen versenyhelyzetek létét ellenőrzi, de önmagában 
még nem elegendő. Ezért a 23. sor megjegyzi azt a pilla- 
natot (pillanatfelvételt készít), amikor a jelenlegi dentry a 
dcache d moveO függvény átnevezési folyamata alá került, 
így később könnyen meg lehet állapítani, hogy volt-e olyan 
átnevezés, amely az útvonalsétával versenyhelyzetbe került 
volna. A 24. sor memóriagátja arra szolgál, hogy a pillanat- 
felvételt se a fordító, se a CPU ne rendezhesse újra. 

A 25-28. sor a szülő dentry-t és a név-hasht ellenőrzi. 
Amennyiben bármelyik hibásnak bizonyulna, ez a dentry 
nem lehet a keresésünk alapja. A 29-41. sor végzi a teljes 
névösszehasonlítást a DEC Alpha gépekhez szánt memória- 
gáttal (30. sor). A 33. sorban láthatjuk, hogy alkalmazha- 
tunk-e fájlrendszerfüggő névösszehasonlító függvényeket 
is (például a kis- és nagybetűfüggetlen fájlrendszerekhez). 
Amint a végrehajtás eléri a 42. sort, megtaláltuk a megfelelő 
névhez tartozó gyermek dentry bejegyzést. Most már 
elkérhetjük a gyermek dentry zárját (42. sor). Minthogy 
valamennyi dentry-bejegyzésen külön zárat alkalmazunk, 
ezeknek az egyedi záraknak a versengési szintje lényegesen 
alacsonyabb, mint az eredeti dcache lock rendszeré volt. 
Sajnálatos módon az élet nem fenékig tejfel, ugyanis pél- 
dául a gyökér dentry lezárása továbbra is versengéshez 
vezet -— de ezzel majd később foglalkozunk. 

Elképzelhető, hogy a gyermek dentry-t már átnevezték 
azóta, hogy a 23. sorban meghívtuk a d move. count pil- 
lanatkép készítését. Ezért a 46-47. sora d move count és 

a pillanatkép értékét hasonlítja össze. Ha az ellenőrzés 
egyezést mutat, a gyermek dentry-t nem nevezték át a 
keresés ideje alatt, és a 48-51. sor növeli a számlálót — de 
csak akkor, ha a bejegyzés még mindig hashelt. 

Az 53. sor elengedi a gyermek dentry zárát, az 54. pedig 
kilép a hasítólánc keresési ciklusából. Az 57. sor sikeres 
keresés esetén a mutatót, sikertelen esetben pedig a NULL 
értéket adja vissza a gyermek dentry-nek. 

Az d lookupO függvény sikertelensége nem feltétlenül 
jelenti azt, hogy a felhasználói folyamat is sikertelenséget 
jelző üzenetet kap. A fájl ettől még létezhet, csak éppen 
még nincsen betöltve a gyorstárba. 

A függvény azonban nem oltalmaz meg bennünket vala- 
mennyi átnevezési verseny kockázatától. Versenyhelyzet 
jöhet létre ugyanis abban az esetben is, amikor a dcache 
listák (list) helyett hlist szerkezetet használ a dcache hasí- 
tóláncokhoz. A hlist listákat memóriamegtakarítás céljából 
alkalmazza, minthogy a hlist listák kettő helyett csak 
egyetlen mutatót tárolnak a lista fejlécében. Ez egyúttal azt 
is jelenti, hogy a listákkal ellentétben a hlist nem körkörös. 
Ezért előfordulhat, hogy egy adott dentry-t úgy nevezünk 
át, hogy az egy korábban üres dcache hasítóláncba kerül. 
Ha ez éppen az adott időben történik, az d lookupO 
függvény (helytelen módon) keresési hibát ad vissza. 

A hibásan visszaadott keresési eredménytelenséget a felsőbb 
szintű d lookupO függvény kezeli, amit a 2. listán mutatunk 
be. A versengő átnevezéseket a read segretryO függvény 
érzékeli a 13. sorban. Mivel a gondot okozó eset kizárólag 
hamis hibajelentést küldhet, az ellenőrzést elegendő csak az 
. d lookupO NULL visszatérési értékeire elvégeznünk. 
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5. lista A dentry-bejegyzések átnevezése 


1 void 

2 d move(struct dentry "dentry, 

3 struct dentry "target) 
4 í 

5 spin lock(gdcache lock); 

6 write seglock(g£rename lock); 
7 if (target c dentry) ( 

8 spin lock(gtarget-sd lock); 
9 spin lock(£gdentry-sd lock); 


10 kh else ( 


11 spin lock(gdentry-sd lock); 

12 spin lock(gtarget-:5d lock); 

13 3 

14 if (dentry-sd vfs flags § DCACHE UNHASHED) 
15 goto already unhashed; 

16 if (dentry-sd bucket !- target-:d bucket) ( 
177 hlist del rcu(Cgdentry-:d hash); 

18 already unhashed: 

19 dentry-:d bucket - target-:d bucket; 

20 hlist add head rcu(Cgdentry-:d hash, 

21 target-:5d bucket); 

22 dentry-:d vfs flags §- -DCACHE UNHASHED; 
5 h 

24 - d drop(target); 


25 list del (£dentry-sd chi1d); 
26 list del (€gtarget-:d child); 
27 switch names (dentry, target); 
28 smp.wmbO ; 

29 do. swi tch(dentry-:d name. len, 


30 target-:d name. len); 

31 do. swi tch(dentry-:d name. hash, 

32 target-:5d name. hash); 

33 if (IS RooT(dentry)) (1 

34 dentry-:5d parent - target-:d parent; 
35 target-s5d parent -— target; 

36 INIT LIST HEAD(£gtarget-:d child); 
AT j else ( 

38 do. swi tch(dentry-:d parent, 

39 target-:d parent); 

40 list add(gtarget-sd child, 

41 $target-:5d parent-5d subdirs); 
42 3 

43 list add(£dentry-sd child, 

44 $dentry-s5d parent-:d subdirs); 


45 — dentry-sd move countt-; 

46 spin unlock(gtarget-:d lock); 
47 — spin unlock(édentry-:sd lock); 
48 write segunlock(grename lock); 
49 spin unlock(€dcache lock); 

50 3 


Halasztott felszabadítás 

Ad freeO függvénynek egy megadott türelmi ideig el 
kell halasztania az adott dentry-hez tartozó területek fel- 
szabadítását, mivel azon a bejegyzésen éppen tetszőleges 
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8. ábra löbbfelhasználós teljesítnénymérés eredménye 


Lp s 


számú folyamatban lévő útvonalséta tarthat mutatókat. 

A d freeO függvényben alkalmazott halasztást a 

3. listában tekinthetjük meg, ahol az 5. sor a call rcuO 
primitív segítségével késleltetia d cal IbackO) pusztíi- 
tóműveleteket, amíg egy adott türelmi idő le nem telik. 

A d callbackO függvény listáját a 4. lista tartalmazza; 

ez — amennyiben szükséges - a külön tárolt fő részeket 
(5-7. sor) egyszerűen felszabadítja, majd a 8. sorban magát 
a dentry-t is felszabadítja. 


Átnevezés 

A d moveO függvény valósítja meg az (átnevezést végző) 
rename rendszerhívás dentry-re jellemző elemeit, ezt 
mutatja be 5. listánk. Az 5. sor kizár minden, esetlegesen 
dcache frissítést végező egyéb folyamatot, majd a 6. sor 
lehetővé teszi ad lookupO függvénynek, hogy megálla- 
pítsa, valóban versenyzett-e valamilyen átnevezéssel. 

A 7-13. sor az átnevezés alatt lévő állomány és annak célja 
számára foglal le dentry elemenként egy-egy zárat, még- 
pedig a holtzárak (deadlock) elkerülése érdekében, cím 
szerint rendezve. A 14-17. sor eltávolítja a bejegyzést a 
dcache hasítótáblában elfoglalt régi helyéről, amennyiben 
az korábban nem törlődött. 

A 19. sor frissíti a dentry bejegyzést, hogy az az új hasító- 
gyűjteményre mutasson; a 20-21. sor felveszi a dentry-t 
a hozzá tartozó cél-hasítógyűjteménybe, végül a 22. sor 
frissíti a jelzőket (flag), mutatván, hogy a dentry a dcache 
hasítótáblában található meg. A 24. sor eltávolítja az (álta- 
lunk átnevezett) cél-dentry-t a dcache hasítótáblából, a 
25-26. sor pedig a mozgató és a cél-dentry-ket választják 
el a régi szülőjüktől. 

A 27. sor megváltoztatja a dentry nevét, a 28. sor pedig 
kikényszeríti az írás újrarendezését. A névváltoztatás 
megoldása nem olyan egyszerű, mivel a rövid neveket 
magában a dentry-ben tároljuk, a hosszabb nevek viszont 
külön lefoglalt memóriahelyre kerülnek. A 29—32. sor 
frissíti a névhosszakat és hasítóértékeket. A 33—44. sor 


a dentry-t csatlakoztatja annak új szülőjéhez. Végül a 

45. sor frissíti add move. count értéket, így az 

. d lookupO felfigyelhet a versenyhelyzetre; végül 

a 46—49. sor kioldja a zárat. 

Elméletben tetszőlegesen szerencsétlen keresést készíthet- 
nénk, a dentry értékeiket mindig azonos könyvtárban és 
azonos hasítóláncban hagyó, gondosan megtervezett átne- 
vezési műveletek folyamatos sorozatával. Az egyik lehető- 
ség, amikor ilyesmi bekövetkezhet, ha a hasítólánc utolsó 
elemét keressük, miközben az utolsó előtti elemet folyama- 
tosan átnevezzük (és az ekként mindig a lista elejére kerül), 
épp mire a keresés odaérne. A gyakorlatban azonban a 
dcache hasítóláncok rövidek, az átnevezés pedig lassú. 
Amennyiben az ilyen elszállások gondot jelentenek, elkép- 
zelhető, hogy ki kell egészíteni a kódot, és útvonalbejárási 
sikertelenség esetén az átnevezést le kell állítani. Egy másik 
lehetséges megoldás szerint teljes egészében el kell távolí- 
tani globális hasítótáblát, és helyette a d subdirs listákat 
szükséges olyan módon megváltoztatni, hogy a nagy 
könyvtárakat elegánsan kezeljék. 


Teljesítmény és összetettség összehasonlítása 

Bár a dcache-kódban végzett változtatás hozzávetőlegesen 
kicsi volt, igen távoli következményei is vannak a rend- 
szermagban, ugyanis ez idáig nem létezett a dcache-sel 
együttműködő, jól körülhatárolt fájlrendszer-API. Ennek 
eredményeképpen rengeteg hiba bukkant fel a Linux 2.5-ös 
rendszermagban, mivel a fájlrendszerkódolók a dcache-t 
hagyományos stílusban, közvetlenül próbálták meg 
módosítani. lekintve, hogy immár létezik egy formálisabb 
API, remélhetjük, hogy a következő változtatások már 
kevésbé lesznek sokkolóak. 

A 8. ábrán egy többfelhasználós tesztprogram teljesítményét 
láthatjuk az RCU-folttal ellátott Linux 2.5.59-es rendszer- 
mag és a folt nélküli mag esetében. A próbákat 16 procesz- 
szoros NUMA-O rendszeren futtattuk, 700 MHz-es 
Pentium III Intel Xeon processzorok felhasználásával, 

1 MB L2 gyorstárral és 16 GB memóriával. 

A dcache. rcu folt alkalmazása a Linux 2.4.17 rendszer- 
magra 2,258-ról 2,530-ra növelte a SPECweb99 (SSL nélküli) 
átviteli teljesítményét egy nyolcprocesszoros Pentium III 
Xeon kiszolgálón, ami 12 százalékos gyorsulást jelent. 
Ugyanezt a foltot alkalmazva a Linux 2.5.40-mm2 rendszer- 
magra a Linux-rendszermag fordítási ideje 47,548 CPU-má- 
sodpercről 42 498 CPU-másodpercre esett vissza, ami több 
mint tízszázalékos gyorsulást jelent. Hasonló próbát fut- 
tatva a Linux 2.5.42 rendszermagot használó egyprocesz- 
szoros 700 MHz-es Pentium III Xeon gépen nem tapasztal- 
tunk változást. Összefoglalva tehát: a dcache RCU nem- 
csak, hogy növeli a felső kategóriás gépek méretezhetősé- 
gét, de gyakran az alacsonyabb kategóriás gépek teljesít- 
ményét is fokozza. 


A jövő irányvonalai 
Bár a 2.6 dcache rendszer sokkal méretezhetőbb, mint 
a 2.4-es változat volt, számos dolog még vizsgálatra szorul: 


1. A frissítések felett továbbra is a dceache lock őrködik, 


így a mélyreható frissítést használó folyamatok nem 
jól méreteződnek. 
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2. A globális hasítótábla miatt a gyorstár nem lehet helyi 
és a frissítési kód a szükségesnél összetettebb lesz. 
Természetesen az alternatíváknak meg kell tartaniuk az 
előd vívmányait, többek közt a nagy könyvtárak nagy- 
teljesítményű kezelését. 

3. A 2.6-ban lévő dcache-kód minden egyes dentry 
d lock spinlock zárját lekérdezi, ami gyorstárvona- 
lon pattogáshoz (bouncing) és atomi műveletvégzés- 
hez (atomic operations) vezethet, különös tekintettel 
a gyökérkönyvtárra és a munkakönyvtárakra. Még 
sokat kell gondolkodni egy igazán egyszerű megol- 
dáson, ugyanis az engedélyeknek a dentry-bejegyzé- 
sekbe történő átmozgatása túlságosan bonyolultnak 
bizonyult. 

4. Az d lookupO és a d moveO közötti versenyhelyzetek 
feloldására használt kód túlzottan bonyolult. 
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Izgatottan várjuk, hogy a 2.7 fejlesztései megoldják ezeket 
a kérdéseket. 


Jogi megállapítások 

Az itt leírtak a szerző álláspontját tükrözik, és nem feltétle- 
nül egyeznek meg az IBM véleményével. A SPEC és a 
SPECweb név a Standard Performance Evaluation Corpora- 
tion bejegyzett védjegye. A teljesítnménymérés kizárólag 
kutatási célokat szolgált és a szabályoktól való következő 
eltérések miatt nem hasonlítható össze a SPECWeb lapján 


található eredményekkel: 


1. Olyan alkatrészeken futott, amik nem felelnek meg a 
SPEC-nagyközönség számára elérhetőnek, a gép 
ugyanis mérnöki mintadarab volt. 

2. Az access log naplót nem tartottuk meg bizonyíték- 
ként. Kiírattuk ugyan, de 200 másodpercenkért le is 
töröltük. 


A legfrissebb SPECweb99-teljesítnénypróbák a 
2 http:/www.spec.org lapon érhetők el. 
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Paul E. McKenney 

Kiváló mérnök az IBM-nél. Régebb óta dolgozik az SMP és 
NUMA algoritmusokon, mint hogy érdemesnek tartaná 
megemlíteni. Ezt megelőzően a packet-radio és internetes 
protokollok témájával foglalkozott (Jóval azelőtt, hogy az 
internet népszerű lett). Hobbijai közé tartozik a futás és 

a szokásos ,ház-asszony-gyerekek" álom. 


Dipankar Sarma 

Jelenleg több Linux-rendszermagprojekten Is dolgozik, 
többek közt a RCU és VES fejlesztéseken. Linuxos kora előtt 
számos egyéb területen dolgozott, többek közt az ABI, OS 
felhozatal, B-K-meghajtók és többösvényű B-K témájában. 


Maneesh Soni 

Az IBM Linux lechnology Központban dolgozik a Linux 
méretezhetőségének fejlesztési projektjén. Nagy tapasz- 
talatokkal rendelkezik a rendszerprogramok, különösen az 
operációs rendszermagok és a fájlrendszerek területén. 
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B-K-utemezők 


Nézzük meg, milyen hatással lesz az új B-K-ütemező megjelenése 
a Linux lemezteljesítményére, illetve milyen előnyöket várhatunk 
a 2.6-os rendszermagban megjelent B-K-ütemezőtől. 


legtöbb Linux-felhasználó tisztában van a folya- 
AA matütemező szerepével (jó példa erre az új O(1) 

ütemező), azonban viszonylag kevesen ismerik 
az B-K (bevitel/kivitel) ütemezők működését. A B-K-üteme- 
zők bizonyos szempontból hasonlítanak a folyamatüte- 
mezőkre: mind a kettő erőforrásokat ütemez több felhasz- 
náló között. A folyamatütemező a rendszeren futó folya- 
matoknak kiszabott processzoridőért felelős. Mit ütemez 
akkor a B-K-ütemező? 
Egy rendszerben nem is feltétlenül szükséges a jelenléte, 
vagyis a folyamatütemezővel ellentétben a B-K-ütemező 
nem elengedhetetlen része az operációs rendszernek. 
Az B-K-ütemező egyedüli , raison dl Itre"-je a teljesítmény. 
Mivel meg szeretnénk érteni a B-K-ütemezők szerepét, át 
kell rágnunk magunkat néhány háttéradaton, ezt követően 
megnézzük, miként viselkedne egy B-K-ütemező nélküli 
rendszer. A merevlemezek az ismerős sáv, fej, szektor 
felosztású, geometriai alapú címzéssel kezelik az adatokat. 
A merevlemez több tálcából áll, ezek mindegyike tartalmaz 
egy-egy lemezt, tengelyt és író-olvasófejet. Minden tálca 
- a CD-khez hasonlóan - további körkörös, gyűrűszerű 
pályákra bontható; végezetül minden ilyen sáv egész 
számú szektorból áll. 
Ha a merevlemezen egy bizonyos adategységet keresünk, 
a meghajtó logikája három adatot vár tőlünk: a sáv, a fej és 
a szektor számát. A sáv mondja meg, hogy melyik körkörös 
pályán találjuk az adatot. Ha a tálcákat egymás fölé helyez- 
zük (miként a merevlemezben is elhelyezkednek), a mega- 
dott sáv egy hengert alkot a tálcákon keresztül (innen szár- 
mazik az angol elnevezése: cylinder, azaz henger). A kérdé- 
ses író-olvasófejet (és ezzel egyúttal a tálcát) a fejadat adja 
meg. A keresést ezáltal egyetlen tálca egyetlen sávjára 
szűkítettük le. Végül a szektorérték azonosítja a sávunk 
adott szektorát. A keresés ezzel befejeződött: a merevlemez 
már tudja, hogy az adat melyik szektorban, melyik sávon 
és melyik tálcán helyezkedik el. Beállíthatja az író-olvasó- 
fejet a megfelelő tálca megfelelő sávja fölé és beolvashatja 
a megfelelő szektort. 
Szerencsére a korszerű merevlemezek már nem kényszerí- 
tik a gépeket arra, hogy sáv-, fej- és szektoralapon tartsák 
velük a kapcsolatot. A jelenlegi merevlemezek minden 
egyes sáv-—fej-szektor hármashoz egyedi blokkszámot ren- 
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delnek. A sáv-fej-szektorértéket ez az egyedi azonosító 
adja meg. A mostani operációs rendszerek e blokkszám 
használatával tarthatják a kapcsolatot a merevlemezzel 

(ezt nevezik logikai blokkcímzésnek), amit aztán a merev- 
lemez a helyes sáv-fej-szektorértékre fordít le magának. 
Ezzel a blokkos címzéssel kapcsolatban egy dolgot érdemes 
megemlíteni: bár garancia nincs rá, a fizikai hozzárendelés 
általában sorban történik, vagyis az n-edik logikai blokk 
fizikailag többnyire az n--1-dik logikai blokk után követke- 
zik. Hogy ez miért fontos, arról később még szó lesz. 

Most nézzünk meg egy átlagos Unix-rendszert: blokkokat 
olvasó vagy kiíró B-K-kérelmeket a lemezen alkalmazások 
széles kínálata, adatbázisok, levelezőügyfelek, webkiszol- 
gálók és szövegszerkesztők használnak. A blokkok fizikailag 
általában összevissza helyezkednek el a lemezen. A posta- 
láda adatai teljesen más helyen lehetnek, mint a webkiszol- 
gáló HIML-adatai vagy a szövegszerkesztő beállításfájljai. 
Igazság szerint létezhet olyan állomány is, amely fizikailag 
az egész lemezen található, amennyiben szét van dara- 
bolva, azaz nem egymást követő blokkokban helyezkedik 
el. Mivel a fájlokat egyedi blokkokba tördeltük, a merev- 
lemez pedig blokkokat kezel és nem a jóval elvontabb 
fájlokat, az állomány adatainak olvasását több, különféle 
blokkokra hivatkozó egyedi B-K-kérelem sorozatára kell 





lebontani. Szerencsés esetben a blokkok sorban helyezked- 
nek el vagy legalább fizikailag közel találhatóak egymás- 
hoz. Amennyiben a blokkok nincsenek közel egymáshoz, 

a lemez fejének egy másik helyre kell mozdulnia a lemezen. 
A lemezfej mozgatását keresésnek (seeking) nevezik, és a 
számítógépen ez az egyik legidőigényesebb művelet. A mai 
merevlemezek keresési ideje tíz milliszekundumokban 
mérhető. Ez az egyik oka annak, amiért jó dolog, ha az 
állományaink töredezettségmentesek (defragmented). 
Sajnos azonban nem igazán számít, hogy fájljaink törede- 
zetlenek-e vagy sem, mivel a rendszer az egész lemezen 
egyszerre több állományhoz hoz létre B-K-kérelmeket. 

A levelezőügyfél egy kicsit innen szeretne, a webkiszolgáló 
egy kicsit onnan... De várjunk csak, a szövegszerkesztő épp 
most szeretne beolvasni egy fájlt. Ez együttesen annyit 
jelent, hogy a meghajtófej összevissza ugrál a lemezen. 

A legrosszabb esetben több állomány együttes B-K-kérel- 
meinél a fej egyfolytában csak ide-oda ugrál, ez pedig nincs 
valami jó hatással a rendszerteljesítményre. 

Ezen a ponton lép be a képbe a B-K-ütemező. Az B-K-üte- 
mező ütemezi a függőben lévő B-K-kérelmeket, a leg- 
kisebbre véve a lemezfej mozgatására fordított időt. Ennek 
megfelelőn csökken a keresési idő és növekszik a merev- 
lemez teljesítménye. 

A varázslat két fő feladat: a rendezés és egyesítés segítsé- 
gével hajtható végre. Először is a B-K-ütemező egy blokk- 
szám szerint rendezett listát tart fenn a függőben lévő B-K- 
kérelmekről. Ha új B-K-kérelem érkezik, blokkszám szerint 
be kell szúrni a függőben lévő kérelmek listájára, így a 
meghajtófejnek nem kell összevissza szaladgálnia a leme- 
zen, hogy a B-K kérelmeket kiszolgálhassa. Amíg a listát 
rendezetten tartjuk, a lemezfej szépen sorban halad a le- 
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mezen. Ha a meghajtó éppen egy kérelmet szolgál ki a 
lemez valamelyik részén és pontosan erre a területre vonat- 
kozó új kérelem érkezik, akkor ezt a kérelmet ki lehet szol- 
gálni, még mielőtt egy másik helyre mozgatnánk a fejet. 

Az egyesítést olyankor használjuk, amikor az azonos vagy Sor- 
rendben következő lemezrészre hivatkozó B-K-kérelem érke- 
zik. Új, önálló kérelem kiadása helyett a kérelmet egyszerűen 
egyesítjük az azonos vagy következő kérelemmel - ezáltal a 
legkisebbre csökkenthetjük a várakozó kérelmek számát. 
Lássunk egy példát! Képzeljük el azt az esetet, amikor két 
alkalmazás a felsorolt blokkszámokra ad ki kérelmeket, és 
ezek a következő sorrendben érkeznek a rendszermaghoz: 
10, 500, 12, 502, 14, 504 és 12. A B-K-ütemező nélküli meg- 
közelítés a blokkokat a megadott sorrendben szolgálná ki, 
ami hét hosszú keresést jelentene, oda-vissza a lemez két 
különböző területe közt. Micsoda pazarlás! Ha a rendszer- 
mag a kérelmeket sorba rendezte és egyesítette volna, és 
ilyen módon szolgálta volna ki őket, ez az eredmény egészen 
más lenne: 10, 12, 14, 500, 502 és 504. Mindössze egyetlen 
távoli keresés és összességében is eggyel kevesebb kérelem. 
Ezzel a módszerrel a B-K-ütemező több B-K-kérelem szá- 
mára teszi elérhetővé a lemezforgalom erőforrását, maxima- 
lizálva a teljes átvitelt. Minthogy a B-K-átvitel meglehetősen 
fontos a rendszer teljesítménye szempontjából és mivel 

a keresések ilyen iszonyatosan lassúak, a B-K-ütemező 
munkája nagyon fontos. 


0 Kiskapu Kft. Minden Jog fenntartva 


A Linus-lift 

A 2.4-es Linux-rendszermagban található B-K-ütemezőt 
Linus liftnek (Linus Elevator) nevezik. A B-K-ütemezőket 
gyakran liftalgoritmusoknak nevezik, mivel hasonló fela- 
datokkal birkóznak meg, mintha egy nagy épületben 
folyamatosan működtetni szeretnénk a liftet. A Linus-lift 
megoldás csaknem pontosan a fent leírt klasszikus B-K- 
ütemezőmodellt követi. A legtöbb szempontból ez kiválóan 
megfelelt, hiszen az egyszerűség jó dolog és a 2.4-es rend- 
szermag B-K-ütemezője valóban jól működött. Sajnos a B- 
K-ütemező teljes B-K-átvitel maximalizálását célzó 
küldetése során engedményt kellett tenni, az ár pedig a 
méltányosság sérülése lett (különösen kérelemlappangás 

— latency — esetén). Lássunk egy példát! 

Vegyük a logikai lemez blokk-kérelmeinek a következő 
sorozatát: 20, 30, 700 és 25. A B-K-ütemező rendező 
algoritmusa a következő sorrendbe rendezné és adná ki a 
kérelmeket (feltételezve, hogy a fej jelenleg a lemez logikai 
kezdőpontjában áll): 20, 25, 30 és 700. Ez az, amire 
számítottunk, eddig nincs is gond. legyük fel azonban, 
hogy a 25-ös blokk kiszolgálása közben egy újabb kérés 
érkezik a lemez azonos részére. Azután egy újabb. Majd 
egy még újabb. Igencsak valószínű, hogy a várólista 700-as 
blokkra hivatkozó kérelme egy jó darabig nem lesz 
kiszolgálva. 

De ez még nem minden. MIi történik, ha a kérelem egy 
lemezblokk beolvasása volt? Az olvasási kérelmek általában 
összehangoltak. Amikor az alkalmazás lemezírási utasítást 
ad ki, általában megáll és várakozik, amíg a rendszermag 

a kért adatot vissza nem adja. Az alkalmazásnak üldögélnie 
kell és várakozás közben malmozhat, míg a 700-as blokk 
kérelmére végre válasz érkezik. Az írás ezzel szemben álta- 
lában nem összehangolt, hanem aszinkron módon műkö- 
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dik. Amikor az alkalmazás kiad egy írási műveletet, 

a rendszermag az írandó adatot és a metaadatot bemásolja 
a rendszermagba, felkészít egy vermet az adat számára és 
visszalép az alkalmazáshoz. Az alkalmazást nem érdekli 

és igazából nem is kell tudnia, hogy az adata ténylegesen 
mikor kerül a lemezre. 

Ettől viszont olvasási kérelem barátunk helyzete csak 
tovább romlik. Mivel az írás aszinkron, általában folyam- 
ként viselkedik, azaz gyakori a nagy mennyiségű adat egy 
idejű visszaírása. Ennek következtében rengeteg egyedi 
írási kérelem kerül a merevlemez közeli területeire. Példa- 
képpen képzeljük el egy nagy állomány mentését: az alkal- 
mazás írási műveleteket küldözget a rendszernek, a merev- 
lemez pedig olyan gyors, amilyen gyorsra ütemezzük. 

Az olvasási kérelmek ezzel szemben általában nem folyam- 
ként viselkednek. Az alkalmazások az olvasási kérelmüket 
apró egyenkénti darabokban adják ki, ahol is minden darab- 
ka az utolsótól függ. Gondoljunk csak egy könyvtár bejegyzé- 
seire: az alkalmazás megnyitja az első állományt, kiadja az 
olvasási kérelmet az állomány megfelelő szakaszára, meg- 
várja a visszaadott adatot, kiadja a következő darab olvasási 
igényét, vár, majd így folytatja mindaddig, amíg az egész 
állományt be nem olvassa. Ezután az állományt bezárja, meg- 
nyitja a következőt - és a folyamat kezdődik elölről. Minden 
soron következő kérelemnek meg kell várnia az előzőt, ami 
igen komoly késedelmet okozhat alkalmazásunk számára, 

ha a kérelmek túlságosan messzi lemezblokkokban találhatók. 
Az a jelenség, amikor a folyamot alkotó írási kérelmek 
koplalásra ítélik a függő olvasási kérelmeket, , írás miatt 
koplal az olvasás" (writes-starving-reads) néven vált ismertté 
(lásd a széljegyzetet: , 1. próba: Írás miatt koplal az olvasás"). 
Annak a lehetőségét, ha egy kérelmet elfogadható időn 
belül nem szolgálnak ki, éhezésnek nevezzük. A kérelmek 
éheztetése igazságtalansághoz vezet. A B-K-ütemezők 
esetében a rendszer a nagyobb átlagos átviteli teljesítmény 
érdekében egyértelműen feladta az igazságosságot. Azaz 

a rendszer megpróbálja növelni a rendszer összesített telje- 
sítményét, bármely egyedi B-K-kérelem lehetséges feláldo- 
zása árán is. Ez elfogadott és tulajdonképpen kívánatos is, 
eltekintve attól, hogy a hosszúra nyúló éhezés nem valami 
jó dolog. Az olvasási kérelmek közepes ideig tartó éhezte- 
tése is nagy lappangási időhöz vezet, ha az alkalmazások 
más lemezműveletek közben próbálnak olvasási kérelmeket 
kiadni. Ez a nagy lappangás hátrányosan érinti a rendszer 
teljesítményét és kényelemérzetét (lásd a széljegyzetet: 

,2. próba: a magas olvasási lappangás hatásai ). 


A határidós B-K-ütemező 

Az új, 2.6-os B-K-ütemezők fő célja pontosan az ilyen 
éhezés elkerülése volt általában a kérelmek, különös 
tekintettel az olvasási kérelmek esetében. 

A 2.4-es B-K-ütemező és általában véve a hagyományos 
liftalgoritmusok körüli nehézségek kezelésére jelent meg a 
határidős B-K-ütemező. Mint azt bemutattuk, a Linus-lift a 
függőben lévő B-K-kérelmek listáját egyetlen sorban tárolja. 
A soron következő kiszolgált kérelem a sor élén álló B-K- 
kérelem lesz. A határidős B-K-ütemező megtartja ezt a sort, 
de egy kicsit megfűszerezi a dolgokat két további sor — az 
olvasási FIFO és az írási FIFO sor -— bevezetésével. A határ- 
idős B-K-ütemező mindkét sorban küldési idő szerint ren- 


36 Linuxvilág 


dezve tárolja az elemeket (azaz lényegében az elsőként 
belépő távozik elsőként, ezt jelenti egyébként a FIFO rövi- 
dítés: first in, first out — a ford.). Az olvasási FIFO sor, mint 
a neve is sugallja, kizárólag olvasási kérelmeket tárol. Az 
írási FIFO sor hasonlóképpen kizárólag az írási műveletek- 
kel foglalkozik. Minden FIFO sorhoz tartozik egy lejárati 
érték: az olvasási FIFO sor lejárati ideje 500 milliszekun- 
dum, az írási FIFO soré pedig öt másodperc. 

Amikor új B-K-kérelmet kapunk, beszúrva a sorba rendez- 
zük, valamint a megfelelő (olvasási vagy írási) FIFO sor 
végére helyezzük. Normál esetben a merevlemeznek a 
rendezett, hagyományos sor tetejéről küldjük a kérelmeket, 
ezáltal maximalizáljuk az átvitelt és minimalizáljuk a kere- 
séseket, hiszen akárcsak a Linus-lift esetében, a normál lista 
blokkszám szerint rendezett. 

Amikor az egyik FIFO sor elején álló elem idősebb lesz, 
mint a sorhoz rendelt lejárati idő, a B-K-ütemező felfüg- 
geszti a normál sor B-K-kérelmeinek a továbbítását. 
Ehelyett a FIFO sor elején álló kérelmeket fogja elküldeni, 
az egyenletesség kedvéért még néhány további elemmel is 
megtoldva. A B-K-ütemezőnek csak a FIFO sorok elején álló 
bejegyezéseket kell ellenőriznie, hiszen mindig ezek lesz- 
nek a legöregebb elemek a sorban. 

Emlékszünk még öreg barátunkra, a 700-as kért blokkra? 

A távoli blokkokat célzó írási kérelmek áradata ellenére 

500 milliszekundum elteltével a határidős B-K-ütemező 
felfüggesztené az ottani kérelmek kiszolgálását és elküldené 
a 700-as blokk olvasási kérelmét. A lemez megkeresné a 
700-as blokkot, kiszolgálná az olvasási kérelmet, majd foly- 
tatná a további várakozó kérelmek feldolgozását. 

Ilyen módon a határidős B-K-ütemező lágy határidőt 
vezetett be a B-K-kérelmekre. Igaz, semmi sem biztosítja, 
hogy a B-K-kérelmek a lejárati idő előtt ki lesznek szol- 
gálva, de a B-K-ütemező általában a lejárati időhöz közeli 
tartományon belül szolgálja ki a kérelmeket. Ennek megfe- 
lelően a B-K-ütemező továbbra is jó, teljes körű átvitelt 
szolgáltat, de mindeközben egyetlen kérelmet sem éheztet 
elfogadhatatlanul hosszú ideig. Mivel az olvasási kérelmek- 
hez gyors lejárati időt adtunk meg, az , írás miatt koplal az 
olvasás" nehézségeit a lehető legkisebbre csökkentettük. 


Jósló B-K-ütemező 

Ez mind szép és jó, de még mindig nem a tökéletes megol- 
dás. Gondoljuk végig, mi történik a képzeletbeli 700-as 
blokkunkkal, amely - tegyük fel -— a lemezterületen számos 
egymástól függő olvasásnak az első tagja. Az olvasási kére- 
lem kiszolgálása után a határidős B-K-ütemező a korábbi 
blokkokban folytatja az előzőleg elkezdett írási kérelmek 
kiszolgálását. Ez rendben is van egészen addig, amíg az 
olvasást végző alkalmazás a következő olvasási kérelmét 

el nem küldi (mondjuk a 710-es blokkra). 500 milliszekun- 
dumon belül ez a kérelem is lejár és a lemez a 710-es blokk- 
hoz szalad, kiszolgálja a kérelmet, majd visszamegy oda, 
ahol az előbb állt és folytatja az írási kérelmek folyamának 
a kiszolgálását. Azután érkezik egy újabb olvasási kérés. 

A feladat ismét azok miatt az átkozott függő írások miatt 
keletkezik! Mivel az olvasást függőben lévő darabok alapján 
végezzük, az alkalmazás csak akkor adja ki a következő 
olvasást, miután a korábbit már visszakapta. Csakhogy 


miközben az alkalmazás megkapja az adatot, a saját futási 


üteméhez ér és elküldi a következő olvasást, a B-K-ütemező 
viszont már továbblépett és egy másik kérelmet szolgál ki. 
Az eredmény minden olvasáskor néhány felesleges keresés: 
kikeressük az olvasás helyét, kiszolgáljuk és visszame- 
gyünk. Mennyivel jobb lenne, ha valami módja akadnak 
annak, hogy a B-K-ütemező megtudja - azaz inkább megjó- 
solja —, hogy érkezik-e újabb olvasás a lemez azonos szaka- 
szára. Előre-hátrakeresgélés helyett egyszerűen csak előre- 
látóan várna a következő olvasásra. A rút keresések kiha- 
gyása biztosan megér néhány milliszekundum várakozást 
és két keresést is kihagyhatunk. 

lermészetesen pontosan ezt teszi a jósló B-K-ütemező. 
Éppen úgy indul, mint a határidős B-K-ütemező: ugyanazt 
a határidő alapú rendszert használja, de ráadásképpen 
jósképességekkel is rendelkezik. Amikor az olvasási kére- 
lem megérkezett, a jósló B-K-ütemező, akárcsak a korábbi, 
határidőn belül kiszolgálja. A határidős B-K-ütemezővel 
ellentétben azonban a jósló B-K-ütemező ezután csak üldö- 
gél és várakozik, semmit sem csinál egészen hat millisze- 
kundumig. Igen jó esély van rá, hogy ez alatt a hat milli- 
szekundum alatt az alkalmazás a fájlrendszer ugyanezen 
részére ad ki újabb olvasási kérelmet. Ha ez bekövetkezik, 

a kérelmet azonnal kiszolgáljuk, és a jósló B-K-ütemező 
még vár egy kicsit. Amennyiben a hat milliszekundum 
olvasási kérelem nélkül telik el, a jósló B-K-ütemező nem jól 
választott, és visszatér ahhoz, amit eddig csinált. 

Mégha csak mérsékelt számú kérelmet sikerül is helyesen 
megjósolni, jelentős időt — darabonként két drága keresést — 
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tudunk megtakarítani (lásd táblázatunkat). Minthogy a 
legtöbb olvasás függő, a jóslás a legtöbb esetben kifizetődő. 
Hogy a helyes jóslás esélyeit tovább növelje, a jósló B-K- 
ütemező heurisztikus módszereket alkalmaz, annak meg- 
állapítására melyik folyamatnak kell várnia. Ennek kivitele- 
zéséhez az ütemező minden folyamathoz B-K-statisztikát 
vezet, nyomon követve annak viselkedését. 

A szükségtelen keresések kiiktatásával és az olvasások gyor- 
sabb kiszolgálásával a jósló B-K-ütemező egyszerre ad kisebb 
kérelemlappangási időt és nagyobb globális átvitelt a határ- 
idős B-K-ütemezőhöz vagy a Linus-lifthez képest. Nem 
meglepő, hogy a 2.6-os rendszermagban a jósló B-K-ütemező 
lett az alapértelmezett. Nagyon helyesen. 


Köszönetnyilvánítás 
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Aláírt magmodulok 


A rendszermag ma már a beillesztésük előtt képes ellenőrizni a modulok 
titkosított aláírásait. Ennek részleteibe avatjuk be olvasóinkat. 
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módon kell a gyakorlatban használni. 

Az aláírt rendszermagmodulok lényege, hogy valaki digi- 
tális aláírást szúr be a modulba, jelezvén, hogy az adott 
modulban megbízik. Senkit sem akarok meggyőzni arról, 
hogy ennek benne kellene lennie a Linuxban vagy feltét- 
lenül szükség van rá, sem arról, hogy növeli a biztonságot. 
Egyszerűen csak azt mesélem el, hogy miképpen lehet 
megvalósítani, és bemutatok egy megoldást, ha esetleg 
valaki használni szeretné. 

Az aláírt rendszermagmodulok működéséhez nyílt kulcsú 
titkosítást használunk. Az RSA nyílt kulcsú titkosítási 


ásik operációs rendszerekben már évek óta is- 
HU mert az aláírással ellátott rendszermagmodulok 

módszere. Bizonyos emberek és cégek hasznos- 
nak tartják, ha kizárólag olyan modulokat (avagy meghajtó- 
kat, ahogy néha nevezik) telepítenek a rendszerükre, ame- 
lyre operációs rendszerük valamelyik hitelesítője (authority) 
az áldását adta. A Linux-rendszermag modulbetöltési mód- 
szerének változását figyelembe véve az aláírt rendszermag- 
modulokat ma már könnyedén a rendszermagba illeszt- 
hetjük. Ez az írás arról szól, hogy miként valósítottam meg 
ezt az elképzelést, valamint azt is bemutatja, hogy milyen 





$ readelf -S visor.ko 
There are 23 section headers, starting at offset 0Xx3954: 


Section Headers: 


INr] Name Type Addr off Size ES Flg Lk Inf AI 
L[ 0] NULL 00000000 000000 000000 00 0 0 0 
[ 1] .text PROGBITS 00000000 000040 0017e€0 00 AX 0 0 16 
[ 2] .rel.text REL 00000000 003cec 000cdO 08 2]. 1 4 
L 3] .init.text PROGBITS 00000000 001820 000210 00 AX 0 0 16 
[ 4] .rel.init.text REL 00000000 0049bc 0001c8 08 21 3 4 
L 5] .exit.text PROGBITS 00000000 001a30 000030 00 AX 0 0 16 
[ 6] .rel.exit.text REL 00000000 004b84 000030 08 2.1 5 4 
L 7] .rodata PROGBITS 00000000 001a60 000020 00 A 0 0 16 
L 8] .rel.rodata REL 00000000 004bb4 000028 08 21 7 4 
[ 9] .rodata.str1.1 PROGBITS 00000000 001a80 000449 01 AMS 0 0 1 
[10] .rodata.str1.32 PROGBITS 00000000 001ee0 0009c0 01 AMS 0 0 32 
[11] .modinfo PROGBITS 00000000 0028a0 0006c0 00 A 0 0 32 
[12] .data PROGBITS 00000000 002f60 000600 00 WA 0 0 32 
[13] .rel.data REL 00000000 004bdc 0001e€0 08 21 c 4 
[14] .gnu.linkonce.thi PROGBITS 00000000 003560 000120 00 WA 0 0 52 
[15] .rel.gnu. linkonce REL 00000000 004dbc 000010 08 21 e 4 
[16] . obsparm PROGBITS 00000000 003680 000180 00 WA 0 0 32 
[17] .bss NOBITS 00000000 003800 00000€c 00 WA 0 0 4 
[18] .comment PROGBITS 00000000 003800 00006€e 00 0 0 1 
[19] .note NOTE 00000000 00386e 000028 00 0 0 1 
[20] .shstrtab STRTAB 00000000 003896 0000bd 00 0 0 1 
[21] .symtab SYMTAB 00000000 004dcc 000760 10 22 58 4 
[22] .strtab STRTAB 00000000 00552c 000580 00 0 0 1 
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algoritmus alapelveiről és működéséről a Linux Journal 

2 http:/www.linuxjournal.com/article/6826 hálózati cikké- 
ben olvashatunk. Ez a cikk feltételezi, hogy az olvasó jártas 
a nyílt kulcsú titkosítás alapjaiban és képes egy új Linux- 
rendszermagot elkészíteni és betölteni a gépébe. Az új rend- 
szermag elkészítéséről és betöltéséről bővebben a Linux 
Kernel Howro-ban (3 http:/wwwi.tldp.org) olvashatunk. 

A 2.5-ös fejlesztői rendszermagsorozatban Rusty Russell 
újraírta a Linux-magmodulok működését. A korábbi rend- 
szermagokban a modulbetöltési logika nagyobbik része a fel- 
használói térben zajlott — Rusty változtatásai révén a teljes 
logika a rendszermagtérbe került; ilyen módon csökkent a 
kiépítésfüggetlen logika, valamint a felhasználói felület is 
lényegesen egyszerűsödött. Ennek egyik kellemes mellékha- 
tásaként mostantól a rendszermag a teljes modulhoz hozzá- 
férhet nyers formában. A magmodul egy egyszerű ELF for- 
mátumú program. Az ELF az executable and linking format 
(végrehajtható és csatoló formátum) szavak rövidítése és a 
végrehajtható programokat jelöljük vele. Az ELF szabványt a 
2 http:/www.muppetlabs.com/-breadbox/sofítware/ELE txt 
címen találjuk meg szöveges formátumban. 

Az ELF-állományok különböző szakaszokra bonthatók. 
Ezeket a szakaszokat tekinthetjük meg a readelf program 
futtatásakor, lásd az 1. listát. 

Minthogy az ELF-fájlok szakaszokból épülnek fel, nem túl 
nehéz egy újabb szakaszt felvenni a modul állományában, 
amit így modultöltés közben a rendszermag a memóriába 
olvas. Ha a modulba egy RSA-aláírásos szakaszt helyezünk, 


for (Ci - 1; i c hdr-se shnum; 16144) ( 
name - secstringstsechdrs[1].sh name; 


/: csak azokkal a szakaszokkal foglalkozunk, 
3 amelyeknek "text" vagy "data" 
olvasható a nevükben"/ 


if ((strstr(name, "text") -—- NULL) €dg 
(strstr(name, "data") -—- NULL)) 
continue; 
/" a ".rel."" szakaszok nem érdekelnek 
3 bennünket. "/ 
if (strstr(name, ".rel.") !- NULL) 
continue; 


temp — (void ")sechdrs[i].sh addr; 
size - sechdrs[i1].sh size; 
do ( 
memset(€sg, 0x00, sizeof(C"sg)); 
sg.page -— virt to page(temp); 
sg.offset - offset in page(temp) ; 
sg.length - min(size, 
(PAGE SIZE - sg.offset)); 
size -- sg.length; 
temp -4- sg.length; 
crypto. digest update(shal tfm, €sg, 1; 
tl while (size 5 0); 
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a rendszermag visszakódolhatja az aláírást és összehason- 
líthatja az éppen betöltött fájl aláírásával. Ha a kettő egye- 
zik, az aláírás érvényes és a modul sikeresen beilleszthető a 
akkor valaki vagy változtatott a modulon, vagy nem a 
megfelelő kulccsal írták azt alá. Ezután a modult elutasít- 
hatjuk - erről szól ez a folt. 


Hogyan működik a rendszermagkód? 

Amikor a rendszermagot valamilyen modul betöltésére 
utasítjuk, a kernel/module.c állományban megadott kód fut 
le. Itt szinte minden feladatot a load module függvény hajt 
végre: a modult megfelelő szakaszokra tördeli, ellenőrzi 

a memóriahelyzeteket és a szimbólumokat, illetve elvégzi 
azokat a további feladatokat, amelyeket egyébként az 
összeszerkesztő program (linker) szokott. A folt ezt a prog- 
ramot módosítja a következő sorok beszúrásával: 


if (module check sig(hdr, sechdrs, secstrings)) ( 
err - -EPERM; 
goto free hdr; 


A module check sig nevű új függvény tartalmazza a mo- 
dul-aláírási logikával kapcsolatos összes részletet. Ha hibát 
ad vissza, akkor Improper Permission hibaüzenetet adunk 
vissza a felhasználónak és megszakítjuk a modulbetöltést. 
Ha a függvény 0 értékkel tér vissza, azaz nem történt hiba, 
s a modulbetöltés folyamata sikeresen folytatódhat. 

A module check sig függvény a kernel/module-sig.c állo- 
mányba kerül. Ez a függvény először is ellenőrzi, hogy 
van-e aláírás a modulban - ezt a következő kódsorokkal 
végezzük el: 


sig index -— 0; 
for (i - 1; 1 ca hdr-se shnum; 1-4-) 
if (strcmp(Csecstrings-issechdrs[i].sh name, 
"module sig") -- 0) ( 
sig index — 1; 
break; 
bi 
if (sig index cz 0) 
return -EPERM; 


A kódrészlet a magmodul valamennyi ELF-szakaszán 
végiglépked, és kikeresi közülük a module sig nevűt. 

Ha az aláírást nem találja meg, hibát ad vissza és megaka- 
dályozza a modul betöltését. Ha megtalálja, folytatódhat 

a függvény végrehajtása. 

Miután a rendszermag megtalálta a modul aláírását, meg kell 
állapítania, hogy milyen nyalábolóérték (hash value) tartozik 
a betöltendő modulhoz. Ehhez létrehozza a rendszermag 
által használt végrehajtható vagy adat-ELF szakaszok SHA1 
nyaláboló értékét. A rendszermagban már megtalálható az 
SHA1 nyalábolók létrehozásához használt kód (egyéb nyalá- 
bolókkal, az MD5-tel és MD4-gyel együtt), így e lépés belső 
logikájának a nagy része már eleve készen van. 

A függvény először az SHA! algoritmus meghívásával fog- 
lalja le a titkosításátalakítási szerkezetet, majd ezt a követ- 
kező kódsorokkal alaphelyzetbe állítja: 
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shal tfm - crypto alloc tfm(C"shal", 0); 
if (shal tfm -—- NULL) 

return -ENOMEM; 
crypto digest init(shal tfm); 


Az ELF-fájl számunkra érdekes részeinek SHA1l nyaláboló 
értékének előállítására az shal tfm változót használjuk, 
mint azt a 2. listán látható kód mutatja. 

A kódban csak azokkal az ELF-szakaszokkal foglalkozunk, 
amelyeknek a neve tartalmazza a , text" vagy a , data" szót, 
de amelyek nem foglalják magukban a ,,.rel." szövegrész- 
letet. Miután az összes szakaszt megtaláltuk és betöltöttük 
az SHAIl algoritmusba, a következő sorokkal az SHAIl 


nyalábolót áthelyezzük az shal result változóba: 


crypto. digest final(shal tfm, shal result); 
crypto free tfm(shal tfm); 


Az SHA1l nyaláboló kiszámításának és az aláírt nyaláboló 
helyének a megállapítása után már csak annyi a dolgunk, 
hogy visszafejtsük az aláírt nyalábolót és összehasonlítsuk 
a számított értékkel. Ezt a lépést a függvény utolsó sorával 
végezzük el: 


return rsa check sig(sig, gshal result[0]); 


Az rsa check sig függvény a security/rsa/rsa.c fájlban 
található és a rendszermagban futtathatóvá alakított eredeti 
GnuPG-kódot használja -— ennek segítségével vissza lehet 
fejteni az aláírásokat és össze lehet hasonlítani az értékeket. 
Működésének pontos ismertetése azonban már 
meghaladná cikkünk kereteit. 


Hogyan működik a felhasználói tér kódja? 

Miután láttuk, hogy milyen módon dönti el a rendszermag, 
hogy a modul helyes aláírással rendelkezik-e, már csak az 

a kérdés, hogy miképpen tesszük azt az aláírást a modulba? 
Két, a felhasználói térben futó program - az extract pkey 
és a mod —, valamint egy apró parancsfájl, a sign található 

a rendszermagfoltban (a security/rsa/userspace/ könyvtár- 
ban). A két programot a könyvtárban található Makefile 
futtatásával fordíthatjuk le. Az extract pkey felhasználá- 
sával a nyílt kulcsot helyezhetjük el a rendszermagban, 

a mod programot pedig a sign parancsfájl használja a 
magmodulok aláírására. 

A modulok aláírásához először is létre kell hoznunk egy 
RSA-aláíró kulcsot — ezt a gnupg program segítségével 
tehetjük meg. Az RSA aláíró kulcs létrehozásához a gpg-nek 
adjuk meg a --gen-key kapcsolót, lásd a 3. listát. 

Sorra válaszolgassuk meg a feltett kérdéseket, és végül 
elkészül az RSA-kulcsunk. A kulcs használatához ugyanak- 
kor el kell készítenünk annak titkosított változatát is. Ehhez 
ismét futtassuk le a gpg-t, és szerkesszük át az imént készí- 
tett kulcsot, lásd a 4. lista (a kulcsomat a listában található 
szövegben testkey-nek neveztem el). 

Mivel mi új kulcsot szeretnénk felvenni, az addkey paran- 
csot gépeljük be: 


Command: addkey 
Please select what kind of key you want: 
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This "ree 
redistribute 1 
ee the file 


This program comes 
This is free softwa 
redistribute it 

1] O 


(2) 
03) 


DSA (sign only) 
ElGamal (encrypt only) 
(5) RSA (sign only) 
(6) RSA (encrypt only) 
Your selection? 


RSA-kulcsra van szükségünk, ezért válasszuk a hatost, és 
válaszoljunk a tennmaradó kérdésekre. Miután a kulcs 
elkészült, gépeljük be a guit parancsot: 


Commands guit 
Save changes? yes 


$1!/bin/bash 
module-$1 
key-$2 


ft emeljük ki a bennünket érdeklő részeket 
./mod $module $module.out 


$ shal alkalmazása a szakaszokra 
shalsum $module.out I] awk "ífprint M$13" 5 
s fmodule.shai 


ff szakaszok titkosítása 
gpg --no-greeting -e -o - -r $key $module.shal 5: 
s $module.crypt 


f a titkosított adat hozzáfűzése a modulhoz 
objcopy --add-section module s1g-$module.crypt 
ss $module 


f ideiglenes fájlok eltávolítása 
rm $module.out $module.shai $module.crypt 


Most már van egy kulcsunk, amivel aláírhatjuk a modu- 
lokat. A modulok aláírásához a sign nevű egyszerű pa- 
rancsfájlt használjuk, lásd az 5. listát. 

A parancsfájl először is a mod programot lefuttatja a mag- 
modulon. Ez a program az ELF-állományból kiemeli a 
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for (section - abfd-ssections; 
section !- NULL; 
section - section-snext) ( 
if (section-sflags § SEC HAS CONTENTS) ( 
if (bfd section size(abfd, section) 
9—-— 0) 
continue; 


/: csak azokkal a szakaszokkal 
foglalkozunk, melyeknek 
"text" vagy "data" olvasható 

a nevükben7/ 
name - section-sname; 


if ((strstr(name, "text") -—- NULL) ég 
(strstr(name, "data") -—- NULL)) 
continue; 


size - bfd section size(abfd, section)); 
data (bfd byte "Jmalloc(size); 


bfd get section contents(abfd, section, 
(PrTR)data, 0, size); 


stop. offset - size / opb; 


for (addr offset -— 0; 
addr offset c stop offset; 
Htaddr. offset) ( 
fprintf(Cout, "9c", 
5 dataladdr offset]); 
T 
free(data); 


használása miatt, úgyhogy egyszerűen közvetlenül befor- 
díthatjuk. 

Először is szükség lesz nyilvános kulcsunknak egy másola- 
tára. Utasítsuk a GPG-t, hogy a kulcsot egy public key nevű 
állományba csomagolja ki: 
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A GPG nyílt kulcsok kezelésének megkönnyítésére néhány 
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Ezután ezt az állományt helyezzük a security/rsa/ könyvtár 
gyökerébe, lecserélve a saját nyilvános kulcsunkat: 


$ mv rsa key.c -/linux/linux-2.6/security/rsa/ 
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0 Kiskapu Kft. Minden Jog fenntartva 


Létrehoztuk a szükséges RSA kulcspárt és a saját nyil- 
vános kulcsunkat a rendszermagkönyvtárba helyeztük. 
Készítsük el a foltozott rendszermagot - ne felejtsük el 
bejelölni a Module signature checking lehetőséget —, majd 
telepítsük. Amint ezt a rendszermagot betöltjük, már csak 
a saját kulcsunkkal aláírt modulokat tudjuk betölteni, 
úgyhogy óvatosan járjunk el: kizárólag fejlesztői gépen 
használjuk a módszert. 


Mi maradt még hátra? 

Mint azt a cikkben bemutattuk, számos lépés szükséges a 

kulcs előállításához, a rendszermag aláírásához és a nyílt 

kulcs rendszermagba történő illesztéséhez. Ez ebben a 

formában egy meglehetősen csiszolatlan fejlesztői projekt. 

Amennyiben a rendszermagfejlesztők és általában a Linux- 

közösség számára elfogadhatóbbá szeretnénk tenni, a 

lépéseket önműködővé kell tenni. Egyszerűbb megoldásra 

van szükség az összes modul aláírásához és a nyílt kulcs 
kezeléséhez is. A képesség leegyszerűsítésének nyilvánvaló 
igénye mellett néhány egyéb elérendő célt is megfogal- 
mazhatunk a projektben: 

e Az RSA-kódot általános titkosító keretrendszerbe kell 
helyezni, hogy azt más rendszermagmodulok is 
használhassák. 

e Lehetővé kell tenni, hogy a rendszermagban egyszerre 
több nyílt kulcs is létezhessen, illetve egyetlen gépen 
többféle forrásból származó modulok is futtathatóak 


legyenek. 
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e Érdemes egyszerűsíteni az aláírási logikát, hogy a GPG 
saját aláírási képességét, esetleg a bsign program meg- 
oldását használhassuk az egyedi mod program helyett. 


Köszönetnyilvánítás 

Szeretném megköszönni az Ericsson fejlesztőinek, hogy 
elkészítették a digsig nevű programot és rendszermag- 
foltot, ezzel téve lehetővé, hogy GPG-változatukat felhasz- 
náljam a rendszermaghoz. Korábban is készítettem ilyet, 
de a megvalósítás borzasztó lett; szerencsére kiadták a 
megoldásukat, ami nagy segítséget jelentett. A digsig 
rendszermagfolt segítségével a felhasználók programokat 
írhatnak alá, a rendszermag pedig semmilyen aláíratlan 
programot nem fog futtatni. A projektről további adatok 

a 5 http:/sourceforge.net/projects/disec címen érhetők el. 
Szeretnék továbbá köszönetet mondani alkalmazómnak, 
az IBM-nek, amiért lehetővé tette, hogy a projekten dolgoz- 
zak, és Don Marti-nak, aki folyton piszkált, hogy készítsem 
el és fejezzem be ezt a cikket. 


Linux Journal 2004. február, 117. szám 


Greg Kroah-Hartman (gregcokroah.com) 

Jelenleg a Linux-rendszerek USB és gyors csatla- 
koztatású (PCI Hot Plug) egységei rendszermagba 
épített meghajtóprogramjainak a fejlesztője. 

Az IBM-nél dolgozik és rendszermaggal kapcso- 
latos kérdésekkel foglalkozik. 


Frissítés 2.6-os sorozatú rendszermagra 


Mint azt a Programvadászatban Is írtam, több dolgot Is 
frissíteni kell, ha a rendszermagnak ezt az új vonalát akarjuk 
használni. 

Az első ilyen nálam (Deblan/GNU Linux Woody) a modconf 


program kényszerű frissítése volt. Bizonyára vannak olyanok, 


akik emlékeznek még a Potato hiányosságaira a 2.4-es soro- 
zat kezelésében - úgy látszik, ez megismétlődik. 

Miután a modullistát üresen találtam, a /etc/apt/sources.list 
fájlban kijavítottam a Woody (vagy ha úgy tetszik: a stable) 
bejegyzéseket, a SID-re kiadtam az apt-get update, apt- 
get install] modconf parancsot. Máris csorgott a hálózatról 
a program új változata, a telepítés után pedig egycsapásra 
megszűnt az előbb említett gond. 

A másik érdekesség számomra az eszközök elnevezése volt, 
ezek közül Is az PS/2-es egeremé. Az X nem tudott elindulni, 
mert nem találta a , Core Pointer"-t, vagyis az egeremet, 
ugyanis eredendően a /dev/bsaux volt a beállításfájlban 
megadva. Ezt /dev/nput/mouseO0-ra kellett kijavítanom. 

A frissítés során talán a legfurcsább helyzet akkor áll elő, ha 
előtte nem initrd-s rendszermagunk volt. (Az initrd egy 
a rendszerindításhoz használt memórilalemez- (ramdisk) fájl.) 
Ha viszont a Debian alatt a gyökérkönyvtárban initrd.img fájlt 
találunk, akkor az azt jelenti, hogy valószínűleg az előző 
rendszermagunk Is initrd-s volt. 
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A rendszerbetöltőnkhöz hozzá kell adnunk az alábbi sorokat, 
különös tekintettel az initrd-bejegyzésre: 


GRUB: 

title Debtan2.6 
root (hd0O0,2) 
kernel /vmlinuz root-/dev/hda3 
initrd /initrd.img 


LILO: 


1mage-/vmlinuz 
label-Linux 
read-only 
1nitrd-/initrd. img 


lermészetesen mindenki a saját rendszeréhez igazítva 
módosítsa a fenti beállításokat . 
A felhasznalók biztosan találkozni fognak ilyen, vagy ehhez 
hasonló dolgokkal, bármelyik Linux-változatot futtassák IS. 
Ha előfordul olyan érdekesség, ami a többi felhasználó 
számára Is hasznos lehet, kérek midenkit, hogy írja meg 
nekem a csontos. gyulaolinuxvilag.hu címre. 

Csontos Gyula 
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Nyomtatókapu közvetlen programozása 


A legtöbb számítógépben, legyen az hordozható vagy asztali gép, 
a mai napig megtalálható a párhuzamos vagy nyomtatókapu (port). 





Centronics kapu elnevezés 
burkoltan az alkalmazott 
protokollt is tartalmazza, de 


ez mára már nem teljesen igaz. Jelen- 
leg a legtöbb nyomtató az IEEFE 1284 
szabvány ajánlásainak megfelelően 
működik, ami lehetővé teszi az önmű- 
ködő felismerést, valamint az egyéb 
kétirányú kapcsolattartást. 

Nos, mire is jó a nyomtatókapu? 
Önként adódik a válasz: nyomtatásra. 
Ez viszont ma egyre kevésbé igaz, 
ugyanis a legtöbb új nyomtató külön- 
böző újabb kapukat használ, legin- 
kább az USB-t, de előfordul — különö- 
sen a hordozható változatoknál — az 
infra vagy a Bluetooth (rádiós) adat- 
átvitel is. Korábban nyomtatókapus 
lapolvasók is léteztek, de ezek hama- 
rabb álltak át az USB-kapura, mint 
maguk a nyomtatók. 

Így viszont egy kissé haszontalannak 
tűnhet a nyomtatókapu, de ha már ott 
van, használjuk valamire! Régebben 

a nyomtatókapuhoz ethernet- (még 
régebben arcnet-) illesztők is megtalál- 
hatók voltak, amelyek - ha némileg 
lassabban is, mint az ,igazi" ethernet, 
de — használhatóak voltak. Ha viszont 
nincs ilyenünk, de két linuxos géppel 
is rendelkezünk és ezeket össze sze- 
retnénk kötni, megtehetjük a dolgot 
magának a nyomtatókapunak a hasz- 
nálatával is. 


Hálózat a nyomtatókapun keresztül 
Előfordulhat, hogy két linuxos gépet 
össze akarunk kötni, de nem azonos 

a bennük található hálózati kártyák há- 
lózatkezelése, vagy csak nem akarjuk 
egy másik hálózatról átállítani, esetleg 
azt a másik hálózatot is el akarjuk érni. 
Megeshet, hogy a régebbi hordozható 
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gépekben nincs is hálózati csatoló. Nos, 

ha van szabad nyomtatókapu a 

gépekben, megoldhatjuk a problémát. 

Mire van hozzá szükségünk? 

e . Mindkét gépben egy-egy szabad 
nyomtatókapura. 

e Egy nullnyomtató kábelre, laplink- 
ként is ismert, esetleg csak egy áta- 
lakítóra, s a nyomtatókábel végére. 

e A gépeken telepített GNU/Linux- 
rendszerre (esetleg más Unixra). 


Mit is kell tennünk? 

1. Először csatlakoztatni kell a kábel 
két végét a gépekhez. 

2. Ha az Ip modult használjuk, akkor 
addig távolítsuk el, amíg a nyom- 
tatókaput a hálózati feladatokhoz 
használjuk (rmmod 1p). 

3. Ha még nincs bent, töltsük be a 
parport modult (insmod parport). 

4. Ezt követően a megfelelő értékek- 
kel töltsük be a parport pc mo- 
dult (például insmod parport pc 
10-0Xx378 irg—7). 

5. A plip modult (insmod plip) is 
töltsük be. 

6. A rendszerüzenetek között nézzük 
meg, hogy a plip kapunk (dmesg) 
milyen eszközszámot kapott, 
ez általában plipo. 

7. A két gépen állítsuk be a csatolót 
(ez az IP-cím csupán szemléltetésül 
szolgál, a lényeg, hogy egymásra 
hivatkozzanak): 
ifconfigplip0o 192.168.10.1 
3 pointopoint 192.168.10.2 up 
illetve 
ifconfigplip0o 192.168.10.2 
3 pointopoint 192.168.10.1 up 

8. A ping utasítás segítségével meg- 
győződhetünk arról, hogy a kap- 
csolat működik-e. 


9. Ha az egyik gép a másikon 
keresztül más hálózatot is el akar 
érni, akkor ezen átjáróként állítsuk 
be a másik gépet: 
route add default gw 
5192.168.10.1 

10. lovábbá a másik gépet állítsuk be 
útválasztónak (azaz engedélyez- 
zük az IP-csomagtovábbítást). 


A Linux nyomtatókapu-illesztője 
Röviden tekintsük át, hogyan is hasz- 
nálják a programok a párhuzamos 
kaput Linux-rendszer alatt. Előbb 
azonban ismét vessünk egy pillantást 
a múltba: a DOS időszakában a hoz- 
záértők számára egyszerű volt a 
különböző kapuk és általában a gép 
alkatrészeinek az elérése — ezt a meg- 
felelő kapucímek írásával és olvasásá- 
val lehetett megoldani. Például, ha 

a nyomtatókapu a Ox3bc címen he- 
lyezkedett el (hogy igazán régi legyen 
a példa, mert ezt a címet általában a 
mono-, Herkules és CGA kártyák 
beépített nyomtatókapuja használta), 
akkor egy 8 bites értéknek a nyom- 
tatókapu adatvonalaira való kiírása 

a következőképpen történt: 


outb(Ox3bc, data) ; 
vagy assemblerben: 
mov dx , 0x3bx 
out dx, ax ; ax-data 

Nos, ez természetesen már a múlté... 
Mivel sokféle nyomtatókapu létezik 
(na jó, nem sok, de többféle, például a 
PC-s változat, a Macintoshé, a Sun 
munkaállomásé), valamint többféle 
csatlakoztatható eszköz van, célszerű 
volt egy illesztőfelületet írni, amit Tim 
Waugh mások segítségével meg is tett. 
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A felépítés lényege, hogy az eszközök 
elérése többrétegűvé vált (ez termé- 
szetesen más elemekre is igaz, nem 
csak a nyomtatókapura). Legalul egy 
közvetlenül az adott vas típusától füg- 
gő modul helyezkedik el, esetünkben 
a parport. pc. Ennek meg is adhatjuk 
a pillanatnyi jellemzőket, ha tudjuk 

— például a betöltése ilyesmi lehet: 


parport pc 10-0x3bc 1rg-none 


A következő modul a parport, amely 
egységes elérési felületet biztosít a 
különböző tényleges kapumegvalósí- 
tásokhoz. Innentől kezdve a nyom- 
tatókapu a gép megvalósításától füg- 
getlenül egységes módon érhető el. 

A parport programozási felületét 

használva működnek a , magasabb" 

szinten lévők: a leggyakoribb az Ip, ez 
valóban nyomtatót illeszt a rendszerbe, 
de ilyen még az előbb látott pl ip is. 

A nyomtatókapu használata a 

parport modul függvényein keresztül 

lehetséges, azonban csak úgy, ha 
rendszermagmodult (drivert) készí- 
tünk. Ennek a modulnak a következő 
feladatai vannak: 

e — Be kell jegyeztetnie magát mint 
a nyomtatókapu felhasználóját 
(registration). 

e — Le kell kérdeznie, hogy milyen 
kapuk vannak a rendszerben 
(ezt visszahívó, azaz callback függ- 
vények segítségével valósítja meg: 
attach és detach). 

e — Le kell foglalnia a kaput (claim), 
ami blokkoló és nem blokkoló 
módon is történhet, azaz vagy vár, 
amíg szabad lesz a kapu, vagy 
nem, ekkor viszont nem biztos, 
hogy sikerült lefoglalni. 

e — Ezután a parport és parport. dev 
szerkezeteken keresztül használ- 
hatja a kaput. 

e A kapu használatát yield típusú 
függvények segítségével ideigle- 
nesen fel lehet adni. 

e — Végül a release függvény segítsé- 
gével a használat jogát más 
folyamatoknak adhatja át. 


A parport modul programozásáról, 
valamint egy ,próba" Ip meghajtó 
írásával kapcsolatban sokat megtud- 
hatunk a Tim Waugh által írt par- 
portbook dokumentumból vagy a 
Linux-mag forrásszövegéhez mel- 
lékelt leírásokból. 
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Közvetlen kapuelérés 

Mint láthattuk, a kapu elérése megle- 

hetősen bonyolult dolog. Ez nagy 

sorozatban gyártott eszközök esetén 
nem annyira nagy baj, mert előbb- 
utóbb úgyis megírja valaki a szüksé- 
ges meghajtóprogramot (esetleg töb- 
ben is, netán magunk is besegíthe- 
tünk). Ha azonban mi magunk akar- 
juk használni a kapukat a saját készü- 
lékünkkel való , beszélgetésre", akkor 
nehezebb helyzetben vagyunk. 

Kedvenc vesszőparipám és munkám 

mellett hobbim is a mikrovezérlők 

programozása. Ezekhez szerettem 
volna egy programbetöltő készüléket 

(régebbi nevén , égetőt") készíteni. 

Mindemellett elsőrendű célom az 

volt, hogy lehetőleg mindenféle 

rendszerből lehessen használni, azaz 

Linux, Windows és - horribile dictu! — 

DOS alól is. Ezért a nyomtatókapu- 

hoz való csatlakoztatás mellett dön- 

töttem. Ennek külön előnye, hogy 
még az újabb hordozható gépeken 

is megtalálható, így mindenfelé hasz- 

nálható lesz. 

A DOS-változattal a fent említettek 

szerint nincs gond, ugyanakkor a 

másik kettőnél jócskán kijutott belőle. 

Mire van szükség egy ilyen készülék 

illesztésénél? Digitális ki- és bemene- 

tekre, mégpedig úgy, hogy mind 
beolvasni, mind kiírni bitenként 
lehessen őket - tehát nem elegendő, 
amit a nyomtatóillesztő programok 
nyújtanak, hogy tudniillik egész báj- 
tokat küldünk a kapura és visszafelé 
csak a nyomtató állapotjeleit (illetve 
azok közül is csak néhányat) olvassuk. 

Lássuk legelőször azt, hogy mit is tud 

nyújtani a nyomtatókapu: 

e  egy8 bites adatkaput, amely 
az újabb gépeken kétirányú, 

a régebbieken csak kimenet; 

e egy 5 bites állapotkaput (status), 
amely bemenet; 

e egy 4 bites vezérlő (control) kaput, 
amely nyitott kollektoros kimenet 
felhúzó ellenállással, és vissza is 
olvasható, így elvileg bemenetként 
szintén használható lenne, de 
ez nem minden gépen működik 
(esetenként más módon van 
megvalósítva). 


A kapuk címei a báziscímhez (B, ami 
a fent említett 0x3bc mellett 0x278 és 
0x378 szokott még lenni, az új BIOS- 
okban választhatóan) a következők: 


e . adatkapu B-1-0 (például: 0x278), 
e  állapotkapu B--1 (például: 0x279), 
e vezérlőkapu B--2 (például: 0x27a). 


Ezeket a címeket szeretnénk írásra és 
olvasásra elérni. Ha az outb és inb 
függvényekkel próbálkozunk, mint 
DOS-ban, akkor szakaszolási hibát 
(segmentation fault) kapunk, lévén, 
hogy az adott ki-bemeneti terület nem 
tartozik a programunkhoz. lehát a 
magon (kernel) keresztül kell elér- 
nünk. Szerencsére a parport modul 
szerzője ioct] hívásokon keresztül 
lehetővé tette a kapu közvetlen írását 
és olvasását. Ezt elég szegényes 
módon említik meg a leírásokban, és 
a neten is kevés ilyen jellegű útmutató 
található, ezért is osztom meg kutatá- 
saim eredményét az érdeklődőkkel. 
Először is akciónk sikeréhez az kell, 
hogy a parport modul (ez pedig függ 
a parport. pc modultól) be legyen 
töltve. Itt említem meg, hogy a 
viszonylag újabb magok (2.4) esetében 
a parport0 eszközfájl (/dev/parport0) 
független az adott kapu báziscímétől: 
mindig az elsőként beállított kapuhoz 
kapcsolódik, a parport1 a második- 
hoz stb. Régebben ezek a fizikai 
címekhez kötődtek. 

Ezután arra van szükség, hogy a fel- 
használó, aki futtatni akarja a prog- 
ramot, írási és olvasási jogosultsággal 
bírjon a parportO eszközfájlon. Ha 
mindez megvan, akkor programunk- 
ban a következő fejlécfájlokat az 
alábbi módon be kell olvastatnunk: 


finclude caunistd.hz 
finclude cfcntl.h:s 
finclude csys/ioctl.hsz 
finclude csys/10.hz 
finclude "ppdev.h" 


Az utóbbi azért a pillanatnyi könyv- 
tárból lesz beolvasva, mert ha nem 
rendszergazdaként és magfordítás 
közben dolgozunk, akkor nincs benne 
(általában csak magfordításnál szük- 
séges), ezért átmásoltam a forrásállo- 
mányok könyvtárába. Iulajdonkép- 
pen ez az utóbbi tartalmazza a 
parport eszközhöz szükséges megha- 
tározásokat. Régebbi rendszereken 
esetleg ppuser.h is lehet a neve, a hasz- 
nálat szempontjából csaknem azono- 
sak. Az adott fájlt a mag forrásfájában 
kell megkeresnünk. 


Miután mindezt megtettük, a követ- 

kező módon használhatjuk a kaput: 

e  hLpt- open("/dev/parport0", 

O RDWR) ; — megnyitja az eszközfájlt. 

e —. joctl](hLpt, PPEXCL , 0) ; — kizá- 
rólagosságot kér a kapura, a kö- 
vetkező hívás előtt kell beállítani. 

e . joctl](hLpt, PPCLAIM, 0) ; — hasz- 
nálati igényt , jelent be" a kapura. 
0 visszaadott érték esetén megvan, 
egyébként nincs. 

e . joctl(hLpt, PPRELEASE, 0); 

— visszaadja a rendszernek a kapu 
használati jogát, utána a 
close(hLpt) hívással be lehet 
zárni az eszközfájlt. 

e — 1oct](hLpt, PPRSTATUS , €data) ; 
— az unsigned char data változóba 
másolja az állapotkapu bitjeinek az 
értékét. 

e — 1oct](hLpt, PPRDATA , $data) ; 

— az unsigned char data változóba 
másolja az adatkapu bitjeinek az 
értékét; ez csak kétirányú változat 
esetén használandó. 

e — 1o0ct](hLpt, PPWDATA , €data) ; 

— a data változó tartalmát az 
adatkapura írja. Amit ide kiírunk, 
az a következő kiírásig változatlan 
marad, azaz a megfelelő logikai 
értéke lesznek a csatlakozó érint- 
kezőin. (Ez a következő vezérlő- 
kapura is igaz). Így felhasználható 
a külső eszközünk vezérlésére. 

e —  1o0ctl](hLpt, PPWCONTROL , €data) ; 
— a vezérlőkapura írja a data 
változó tartalmát. 

e — 71octl](hLpt, PPRCONTROL , data) ; 
— beolvassa a vezérlőkapu bitjeit. 
Ez nem biztos, hogy ugyanaz, 
mint amit kiírtunk, mivel külső 
eszköz megváltoztathatja a logikai 
szinteket, valamint a lentebb 
említett módon bizonyos bitek 
invertálódnak. 

e . Emellett vannak még a kétirányú 
változatok adatirányát beállító, az 
ezekhez tartozó kibővített vezérlő- 
regisztert, a FIFO tárolót, és a 
magasabbrendű protokollt segítő 
hívások, de ezek túlmutatnak 
cikkünk témáján. 


Mint azt a korábbiakban megemlhkí- 
tettem, az állapot- és vezérlőkapunak 
van néhány furcsa sajátossága. Az 
állapotkapu csak 5 bites, ezek a bájt 
felső részén olvashatóak, azaz az alsó 
három nem valós érték. Ráadásul a 
legfelső bit invertált, azaz a csatlako- 
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zón lévő logikai szint ellentétét mu- 
tatja. (A miértekre nem tudok felelni, 
valószínűleg így jobban megfelelt az 
eredetileg kialakított protokollnak.) 
lehát, ha a kapun lévő valódi adatot 
meg akarjuk kapni, akkor a data-data 
NA 0x80; utasítással meg kell ezt a bitet 
fordítanunk (ez egy bináris xor mű- 
velet, ha a műveleti jel netán ismeret- 
lennek tűnne). 

A vezérlőkapunál is vannak érdekes- 
ségek: ez csak 4 bites, de ezek a bájt 
alsó részén helyezkednek el. Ráadásul 
több is invertált. Így a következő mó- 
don kell kiírnunk az adatot, ha azt 
akarjuk, hogy az 1 állapotú bitek logi- 
kai 1 értéket jelentsenek a csatlakozón: 


data-data A OxOb; 


A kiírást követően, hogy a felső bitek 
ne zavarjanak (mivel néhány esetben 
ezek közül valamelyik vezérli a két- 
irányú adatkapu irányát, esetleg a 


ME ak 


megszakítási jel előállítását is): 
data-data £ OXxOf; 


Ezután már kiírhatjuk a kapott 
adatokat a fent látott ioct1 (hLpt , 
PPWCONTROL , €data) ; hívással. 

Mint látjuk, némi küzdelem árán 
elérhetjük, hogy kedvenc Linux-rend- 
szerünkből is ugyanúgy kezeljük 

a párhuzamos kaput, mint régen, 

a , mindent szabad" DOS-os időszak- 
ban. Ez előnyös lehet, ha saját építésű 
vagy más okból a rendszer által nem 
támogatott készüléket akarunk mű- 
ködtetni. Ilyen esetben a nehéz- 

kes kipróbálás miatt elég munkás a 
további fejlesztést C-ben végezni; 
erre jelenthet megoldást a - talán egy 
későbbi cikkben ismertetésre kerülő — 
beágyazott forth rendszer használata, 
amelyből megfelelő ingyenes, nyílt 
forrású változatot Linuxra is 
találhatunk. 


Havránek Ferenc 
(hf(odelvidek.hu) 
Automatikamérnökként 
dolgozik. Kedvtelései 
közé tartozik mindenféle 
kétkerekű járművön 
(kerékpár és motor) való közlekedés. 
Ezenkívül szívesen tölti idejét progra- 
mozással, nemcsak PC-s, hanem 
egyéb környezetben is, például mikro- 
vezérlő programokat Ír. 
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Személyi videófelvevő építése 


mi 


.Od 


Csatlakoztassuk műholdas lavórunkat egy személyi számítógép alapú 
felvevőhöz, amelynek segítségével időeltolást végezhetünk kedvenc 
műsorainkban, archív másolatokat készíthetünk és a beépülő modulok 
segítségével milliónyi egyéb feladatot is megvalósíthatunk! 


anapság a tévéműsorok 
felvételét és szerkesztését 
egyaránt digitálisan végzik 
— mi mégis analóg rendszereken, 
kábelen, műholdon vagy földi állo- 
mások adásain keresztül vesszük őket. 
Nem is tudom, akad-e még valami 
előnye ennek a megoldásnak. Szeren- 
csére létezik egy másik lehetőség is, 
amely jobb képminőséget, Dolby 
Digital hangot és elektronikus műsor- 
füzetet (Electronic Program Guide, 
EPG) kínál. Hölgyeim és uraim, 
ismerkedjenek meg a DVB, a digitális 
műsorszórás (digital video broad- 
casting) világával! 

A DVB egy MPEG-2 tömörítésű folya- 
mot továbbít, legnagyobb sávszéles- 
sége 15 Mbit/s. A DVB-t sosem hasz- 
nálták csupán videofolyam továbbítá- 
sára, a hang és az egyéb szolgáltatá- 
sokhoz szükséges adatok küldésére 
külön sávokat alkalmaznak. Minden 
adat kisméretű csomagokban utazik 
— természetesen, ha egyes csomagok 
kimaradnak vagy sérülten érkeznek 
meg, akkor a képen és a hangban is 
lehetnek hibák. A műsor azonban a 
helyesen megérkező csomagok adatai 
alapján megy tovább, mintha mi sem 
történt volna, vagyis összehangolási 
kérdésekkel nem kell foglalkoznunk. 
Különösebb bajok a jel vételével sem 
lehetnek, az antennákat általában úgy 
méretezik, hogy az eső, a hó vagy a 
kisebb állatok ne zavarják a tévézést. 
A DVB három változatban létezik: 

a DVB-S műholdas, a DVB-C kábeles, 
a DVB-I pedig felszíni sugárzású 
rendszert takar. Alapvetően mindhá- 
rom rendszer ugyanaz, különbséget a 
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vevőegységekben találni. A DVB-I 
eléggé új megoldás, még nem nagyon 
terjedt el, a másik kettő azonban 

— főleg a műholdas - világszerte széles 
körben kedvelt. 


Epítkezzünk! 

A nagyobb gyártók korszerű set-top 
boxai érdekes lehetőségeket kínálnak, 
például képesek felvételeket készíteni 
merevlemezre, illetve az MP3 formá- 
tumú fájlokat is lejátsszák. Komolyabb 
dolgokat azonban nem tudnak, pél- 
dául SVCD vagy MPEG-4 formátum- 
ban nem tudunk velük felvételeket 
menteni. Mivel a DVD-írók és a -le- 
mezek ma már megfizethetők, ked- 
venc tévéműsoraink DVD-re írása 
egyáltalán nem megvalósíthatatlan 
ötlet. Európában a digitális személyi 
videófelvevők (PVR) ára sajnos 500 
dollár (nagyjából 110 ezer forint) körül 
mozog, és a legtöbb modellben nincs 
merevlemez. Egy nagy tudású DVB-S 
kártya viszont akár 165 euróért is 
beszerezhető a webes boltokból. 

Mit ér azonban az olcsó vas, ha nincs 
hozzá megfelelő alkalmazás? A VDR 
alkalmazás segítségével, valamint 

a saját választásunk szerinti Linux- 
változattal és DVB-kártyával saját 
nagy teljesítményű set-top boxot épít- 
hetünk. Az általam összeállított gépen 
lehetett tévézni, műsorokat rögzíteni 
és időeltolást végezni bennük, vala- 
mint különleges szolgáltatásokra is 
képes volt, például MP3/Ogg-fájlok 
lejátszására, az MPlayer által ismert 
formátumok megjelenítésére és a 
felvett anyagok MPEG-4, video-CD 
vagy DVD formátumban történő 


archiválására. Egy készen vásárolt set- 
top boxnak bizony keményen össze 
kell szednie magát, ha ilyen széles 
körben akar szolgáltatásokat nyújtani. 


A vas kiválasztása 

A gép összeállításához megfelelő 
alkatrészekre van szükség. Először is 
ne feledjük, hogy a felvételek renge- 
teg helyet foglalnak el. Egy 120 GB-os 
merevlemezre nagyjából 60 órányi 
videóanyag fér, ami átlagos esetben 





T. kép A VDR főmenüje az Elchi folt 
telepítése után 





2. kép A távirányító gombjainak megadása 


bőven elegendő. Ha a filmeket gyak- 
ran archiváljuk és ilyenkor eltávolít- 
juk őket a merevlemezről, akkor akár 
egy kisebb merevlemezzel el is 
boldogulhatunk. Javaslom azonban, 
hogy 20 GB alá ekkor se menjünk 
— egy ekkora területen 3-4 film még 
kényelmesen elfér. 
Gyors processzorra is szükség lesz. 
Ha a videóanyagokat tömöríteni, 
kódolni szeretnénk, akkor jó gyors 
kell, ha nem, akkor egy öregecske, 
200 MHz órajelű is megteszi. Manap- 
ság újonnan 













1700 MHz-es 


Celeronnál lassabbat nem kapunk, 
ami mindenféle feladatra bőségesen 
elegendő teljesítménnyel bír. A leját- 
szásokhoz használt MPlayer szintén 
gyors processzort igényel, legalább 

1 GHZ órajelút; bár a pletykák szerint 
gyengébbel is működik. Én lassabb 
gépen is kipróbáltam az MPlayert és 

a képminőség bizony nem volt tökéle- 
tes. Mindennek oka abban a módszer- 
ben keresendő, ahogyan az MPlayer a 
DVB-kártya MPEG-2-dekóderét hasz- 
nálja. A nem MPEG-1/2 formátumú 
anyagokat a program menet közben 
MPEG formátumúra hozza, ami leköt 
némi teljesítményt. 

Ezzel el is érkeztünk a legfontosabb 
összetevőhöz, a DVB-kártyához: nagy 
tudású, beépített MPEG-dekóderrel 
rendelkező példányra van szüksé- 
günk. Az ilyen kártyák ugyan drágáb- 
bak, de számos hang- és tévécsatlako- 
zóval rendelkeznek. A WinTV Nova 
és a hozzá hasonló kártyák inkább 
másodlagos választásnak jók, ha egy- 
szerre több műsort is rögzíteni akar- 
nánk. Ha tehetjük, a műholdas megol- 
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dást válasszuk; ez messze a legrugal- 
masabb rendszer, ugyanis semmilyen 
kábeles szolgáltatótól nem tesz ben- 
nünket függővé. Azt is megtehetjük, 
hogy több műholdas antennát állítunk 
üzembe, és így több csatorna vételi 
lehetőségét teremtjük meg. A továb- 
biakban a DVB-S változatról lesz 
szó, de a másik kettő beüzemelése is 
nagyon hasonló módon történik. Kár- 
tyaként én a Hauppauge Nexus-s 
típus mellett döntöttem, ami aligha- 
nem a legdrágább választás, viszont 
a régebbi modellekkel ellentétben 
nincsenek túlmelegedési gondjai, jó 
a vevőegysége, valamint infravörös 
távirányító is jár hozzá. 
lovábbá a Red Hat Linux 9-es 
mellett kötöttem 
ki, de bár- 
melyik válto- 
zat megfelelő. 
Legyen a 
gépen GCC, 
fejlesztői 
csomagok 
és libjpeg, 
a többire ne is 
legyen gondunk. 
Az X megléte sem létkérdés, a jobb 
DVB-kártyák videokimenettel is bír- 
nak. A rendszermag-fejlesztői csoma- 
gokat se felejtsük el telepíteni, a 
DVB-illesztőprogram fordításakor 
szükség lesz rájuk. 


A meghajtóprogramok telepítése 
Ha a kiválasztott terjesztés alapele- 
meit telepítettük, akkor fel kell ten- 
nünk a kártya meghajtóprogramját is. 
A CVS-változat a 3 http://linvdr.org/ 
download/vdr/Developer címen 
érhető el; írásom születésekor a linux- 
dvb.2003-09-05.tar.bz2 a legfrissebb 
kiadás (az 57. CD Magazinr/Video 
könytárában megtalálható a legfris- 
sebb linux-dvb.2003-11-08.tar.bz2 vál- 
tozat). A legújabb meghajtóprogram 
időnként lefagy, ha a műholdas kábelt 
lehúzzuk vagy a vételi szint a nullára 
esik. Ilyenkor el kell távolítani és újra 
be kell tölteni az meghajtóprogramot, 
ami viszont nem mindig lehetséges 

— ebben az esetben nem marad más 
lehetőségünk, mint újraindítani a 
gépet. A lefagyások eléggé bosszan- 
tóak, ha éppen felvennénk valamit 
vagy pont egy film közepén járunk, 
de szerencsére elég ritkán keserítik 
meg az életünket. 


Lépjünk be a /usr/src könyvtárba, cso- 
magoljuk ki az meghajtóprogramot, 
majd a könyvtárát nevezzük át DVB-re. 
Az átnevezés fontos mozzanat, szá- 
mos folt és beépülő modul ugyanis 
könyvtárnevek alapján működik. Lép- 
jünk be a DVB könyvtárba és a make 
parancs kiadásával indítsuk el az 
meghajtóprogramot, valamint a hozzá 
társított — például a műholdak letapo- 
gatásával a csatornák listáját vissza- 
adó — segédprogramok lefordítását. 

A make install] parancsra nem lesz 
szükségünk, a modulok betöltését a 
runvdr parancsfájl végzi. A fordítás 
befejezését követően ne mulasszuk el 
a makedev.napi parancsfájlt lefuttatni 
— ez hozza létre a szükséges bejegy- 
zéseket a /dev könyvtárban. 


Csatornák keresése 

Ha Európán kívül lakunk vagy nem 
az Astra műholdakat vesszük igénybe, 
akkor más lesz a csatornalistánk. 

A csatornák keresése önműködően 
történik. A DVB-meghajtóprogramhoz 
tartozik egy scan nevű segédprogram, 
ezt a /apps/scan könyvtárban találjuk. 
A -o vdr kapcsolóval kell meghívni, 
ekkor a kimenet a VDR csatornafor- 
mátumában fog előállni. Ha a prog- 
ram által adott csatornalistát fájlba 
szeretnénk menteni, a szabványos 
kimenetet az alábbi paranccsal kell 
átirányítanunk: 


./scan -o vdr 5 channels.conf 


A VDR telepítése 

Töltsük le a vdr-1.2.5.tar.bz2 csomagot, 
bontsuk ki a /usr/src könyvtárba, majd 
lépjünk be. A VDR telepítése nem 
mindig egyszerű. Iudását különféle 
foltokkal feljavíthatjuk, csakhogy ha 
nem figyelünk eléggé, a sok foltoz- 
gatásba hamar belezavarodhatunk. 
Ha nagyszámú foltot szeretnénk fel- 
tenni, a legjobb az, ha egyesített folt 
formájában szerezzük be őket. Én az 
Elchi folton kívül mást nem hasz- 
náltam, ez a VDR csúnyácska 
alapértelmezett felhasználói felületét 
dobja fel egy kicsit. Ha figyelünk rá, 
hogy az adott VDR-változathoz ké- 
szült foltot használjuk, nem lesz vele 
különösebb gondunk. 

A beépülő modulok rengeteg szolgál- 
tatást nyújtanak, az elektronikus levél- 
ben küldött értesítésektől kezdve 
egészen a , fullextrás" DVD-lejátszásig. 
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3. kép Az adatsorban a csatorna neve, az éppen futó műsor 
címe és a következő műsor címe látható 


A következőkben két beépülő modul 
telepítéséről lesz szó: az egyik a táv- 
irányítót kezeli (remote), a másik az 
MFP3/MPlayer-lejátszást teszi lehetővé. 
A remote beépülő modulra csak akkor 
van szükség, ha eredeti Hauppauge 
távirányítót használunk, az 
MP3/MPlayer ellenben hétköznapi 
halandó gépéről nem hiányozhat. 
Lépjünk be a /usr/src/vdr-1.2.5/ 
PLUGINS/src könyvtárba és bontsuk 
ki a két csomagot. A VDR-féle 
makefile nem végzi el a beépülő mo- 
dulok fordítását, amíg a könyvtár- 
nevekből ki nem vesszük a változat- 
számot. A két könyvtárat tehát remote 
és MP3 névre kell átkeresztelni. 

Az mp3 beépülő modul működéséhez 
bizonyos további elemekre is szükség 
van, kicsit ,kézzelfoghatóbban": ez 

a libsndfile, a libmad és a libid3tag. 
Mivel a Red Hat-változatok MP3-tá- 
mogatást nélkül készülnek, kézzel kell 
telepítenünk őket. Mindhárom össze- 
tevőt a 5 http:/www.freshrpms.org 
címről kiindulva szerezhetjük be. 

Ha mindent beállítottunk, írjuk be 

a make REMOTE-plugin NEWSTRUCT-1 
all plugins parancsot. 

A REMOTE-plugin kapcsoló a hasz- 
nálható beviteli módszerek körét 

a remote beépülő modullal bővíti. 

A Lirc segítségével kiválaszthatjuk, 
hogy milyen távirányítónk van. A vi- 
deómagnókhoz készült példányokkal 
egészen jól boldogulhatunk, ilyenkor 
a REMOTE-l irc kapcsolót kell alkal- 
maznunk. A billentyűzet támogatása 
alapállapotban engedélyezve van, 

és jobb, ha ezen nem is módosítunk 
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- hibakereséskor 
még jól jöhet. 

A NEWSTRUCT-1 
kapcsoló feladata 
az, hogy a beépülő 
modulokkal közölje, 
hogy az új meghaj- 
tóprogramokat a 
fusr/src/DVB könyv- 
tárban kell keresniük. 
Mindent lefordí- 
tottunk, nincs más 
hátra, mint az indí- 
tóparancsfájl átírása. 
Alapként használjuk 
a remote beépülő 
modulhoz mellékelt 
példányt. A neve 
runvdr.remote, a misc 
könyvtárban találjuk. 
A parancsfájl egy billentyűtérképet 
tölt be, ezzel végzi a távirányítóról 
érkező jelek dekódolását. Minderre 
csak a Hauppauge infravörös vevő- 
egységének használatakor van szük- 
ség. Ha nincs ilyenünk, akkor a 
parancsfájl szerkesztésekor a VDR 
gyökérkönyvtárában található runudr 
parancsfájlból induljunk ki. Mozgas- 
suk át a runvdr.remote parancsfájlt a 
VDR gyökérkönyvtárába, majd indít- 
suk el a kedvenc szövegszerkesztőn- 
ket. A 24. sorban találjuk a vdr indítá- 
sát szabályozó kapcsolókat, amelyek 
nálam így néztek ki: 


VDRCMD-—" $VDRPRG -w 60 -P scanner 
sz-PUmplayer -M 
s /video/plugins/ 
ssmplayer.shvV 
5-P mp3 -PN"remote -i 

ss /dev/input/eventíNV " $" 


Ha bizonytalanok vagyunk abban, 
hogy mit kellene beleírnunk a fájlba, 
adjuk ki a vdr -help parancsot, amely 
az összes használható modult és a 
hozzájuk tartozó kapcsolókat is meg- 
jeleníti, köztük a VDR kapcsolóit is. 
Aggodalomra semmi ok, könnyen 
meg fogjuk találni, mivel kell bővíte- 
nünk a fájlt. Szükségünk lesz még egy 
alapkönyvtárra is, ennek alapértel- 
mezett helyét a Make.config adja meg, 
a neve /video. Minden beállításfájl és 
rögzített képanyag ebbe a könyvtárba 
kerül. A sources.conf fájlt és saját 
channels.conf fájlunkat másoljuk a 
/video könyvtárba. 

Az egyetlen dolog, ami még várat 


magára, az MPlayer/MP3 beépülő 
modul beállításfájljainak az elkészí- 
tése. Kezdjük azzal, hogy létrehozzuk 
a /video/plugins könyvtárat. Két fájlra 
lesz szükségünk, az egyik az 
mp3sources.conf, a másik az 
mplayersources.conf. Nem kell félni, 
különösebben egyikkel sem fogunk 
megszenvedni. A kezdők az 
mp3sources.conf fájlba annyit írjanak, 
hogy /video/music; Local files;0, 
az mplayersources.conf fájlba gépeljék 
be a /video/compressed; Local 
files; 0 karakterláncot, majd mind 

a két fájlt mentsék. Ahhoz, hogy az 
MPlayer a DVB-kártyával együtt 
tudjon működni, újra kell fordítani. 
Töltsük le a forrást a 

2 http:/www.mplayerhg.hu oldalról, 
majd a --with-extraincdir-/ 
usr/src/DvB/include kapcsolóval 
gondoskodjunk a saját beállításaink 
érvényre juttatásáról. Futtassuk le a 
configure parancsfájlt, fordítsuk újra 
a programot, telepítsük — és elvileg 
végeztünk is. 

Amint a runvdr parancsfájlból is 
kiderül, az MPlayer beépülő modul 
egy különleges héjparancsfájl, az 
mplayer.sh segítségével indítja az 
MPlayert; ezt a 

2 http:/batleth.sapienti-sat.org/ 
projects/VDR címről szerezhetjük be. 
A csomagban mindössze két fájl 
található, maga az mplayer.sh és az 
mplayer.sh.conf, az utóbbi néhány 

az MPlayer alapú lejátszáshoz túl 
lassú, akkor az ebben a fájlban 
található beállítások módosításával 
próbálhatunk meg javulást elérni. 


Könyvtárak 
2 http:/Avww.freshropms.org 


tElESE 
2 http:/Avwwv.lirc.org 


MPlayer 
2 http:/Avwvw.mplayer.hu 


mplayer.sh 
2 http://batleth.sapienti- 
sat.org/projects/VDR 


Beépülő modulok, parancsfájlok 

és foltok a VDR-hez 

2 http:/Avww.vdrportal.de/board/ 
portal downloads.php?site-6 





Lassan kép is lesz? 

Lépjünk vissza a /usr/src/vdr-1.2.5 
könyvtárba és futtassuk a 
runvdr.remote fájlt. Ha Red Hatet 
használunk, akkor végezzük el az 

LD. ASSUME. KERNEL-2 .4.1 környezeti 
változó értékadását, a VDR ugyanis 
egyelőre nem működik a Red Hat által 
a legújabb változattal bevezetett natív 
Posix-réteggel. Sor kerül a DVB-kártya 
működéséhez szükséges modulok be- 
töltésére, majd a VDR elindul. Kapcsol- 
juk be a tévét: fekete képernyőt kell 
látnunk, amely a távirányító gombjai- 
nak megadását kínálja fel. A varázsló 
futtatásának befejezése után készen 
állunk arra, hogy tévézzünk, felvéte- 
leket készítsünk, eltávolítsuk a reklá- 
mokat, MP3-at hallgassunk vagy 
videófilmeket nézzünk. A VDR gyö- 
kérkönyvtárában található egy kézi- 
könyv, amely a műsorok rögzítését, 
szerkesztését és az időeltolás-szolgál- 
tatás használatát taglalja. 


Archiválás 
Senki ne búslakodjon amiatt, hogy 
lassan végére ér a cikknek — bőven 
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van még mit tenni, ha győzzük kedv- 
vel és fáradtsággal. Mindjárt nézzük is 
meg például az önműködő archiváló 
szolgáltatást — sajnos akad néhány 
korlátja. Az (5)VCD mentés még gond 
nélkül működik, DivX alapú tömörí- 
tésnél viszont a program nem távolítja 
el a kép szélén található fekete csíko- 
kat. Mindez eléggé hátrányosan 
befolyásolja a bitszámot, a méretet és 
az összesített képminőséget. Ha való- 
ban jó minőségű, kisméretű MPEG-4- 
állományokat szeretnénk kapni, az 
archiválást kézzel kell elvégeznünk. 

A jelentősen javuló képminőség bő- 
ven kárpótol a fáradozásért. 

A VDR a felvételeket 2 GB-os fájlokra 
osztja, ami a mozgóképek átkódolá- 
sakor finoman szólva is: kényelmet- 
len. Ha az átalakítást kézzel végez- 
zük, márpedig érdemes így eljárnunk, 
hiszen pontosabban tudjuk szabá- 
lyozni a minőség/méret mutatót, a 
mencoder vagy a transcode megfelelő 
választást jelent. A mencoder gyors, 
MPEG-4 formátumú mentésekhez 
tökéletesen megfelel, a transcode 
viszont bőséges körítéssel bír. Ha nem 





akarunk sokat vacakolni, a 
VDRCONVERI a mi barátunk. 

A README tájlban egyszerű 
telepítési leírást is találunk hozzá. 
Amíg letöltjük és lefordítjuk a 
programot, akár tévézhetünk is egyet. 
Ha lakhelyünkön NISC szabványt 
használnak PAL helyett, akkor a 
VDRCONVERI-hez tartozó parancs- 
és beállításfájlok tartalmát módosí- 
tanunk kell, hogy a DVD/AS) VCD 
anyagok felbontása is tükrözze a 
szabvány előírásait. 

Az egyetlen nagy baj az, hogy hiába 
van egy kiváló linuxos személyi videó- 
felvevőnk, a tévéműsorok nem lesz- 
nek jobbak. Sajnos ebbe kénytelenek 
leszünk belenyugodni — minden nem 
megy egyszerre, nem igaz? 


Linux Journal 2004. január, 114. szám 


ül Christian A. Herzog 
(noeffredeogmx.net) 
Webes és nyílt forrású 
megoldásokkal foglalkozó 


tj A. programozó. 
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Debian otthon (4. rész) 


A múlt hónapban a különböző hangrendszerekről szóltam, de igazán csupán 
addig jutottunk el, hogy valamiféle nyikorgást tudtunk előcsalni a gépből. 


hogy írtam, a számomra legkényelmesebb mód- 
szer a gép által támogatott hangrendszerek kipró- 
bálására az xmms használata. Nem kell más, csupán 
valamilyen hangfájl, majd a Beállítások ablakban (CTRL--P) 
kiválaszthatom a kívánt kimeneti modult (ALSA, OSS, ESD, 
vagy DiskWriter). A DiskWriter kimenet, ahogy azt a neve 
sugallja, nem megszólaltatja a lejátszott számot, hanem 
nyers WAV formátumban a lemezre írja. 

De honnan kapar össze az ember zenét kipróbálási célzattal? 
A legkézenfekvőbb a hanglemez használata. Mindenki ren- 
delkezik hivatalos hanglemezekkel, még az is, akinek házilag 
írott lemezei vannak. Mert ugyebár elméletileg a kis Artisjus- 
címkékért azért fizetünk, hogy jogosan írhassunk minden- 
féle zenét lemezeinkre. Ha rendszeresen hallgatsz hangleme- 
zeket, előbb-utóbb keresel majd valamilyen kényelmes meg- 
oldást, ami egyszerű és az általad igényelt szolgáltatásokat 
nyújta. Például legyen képes lekérdezni a lemez tartalom- 
jegyzékét az internetről. Mert mire jó az informatikai szuper- 
hipersztráda, ha nem a kényelmi szolgáltatásokra? Létezik 
egy szolgáltatás, a CDDB, amelynek lényege, hogy lelkes fel- 
használók begépelgetik a lemezeik tartalomjegyzékét, majd 
amikor bárki a világon egy ugyanolyan szerkezetű lemezt 
kezd el hallgatni, a rendszer a már begépelt tartalomjegyzé- 
ket magától letölti. 
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Tényleg csak érintőlegesen, de azért nézzünk bele a hangle- 
mezlejátszók listájába! 

A két nagy környezet, a Gnome és a KDE alaplejátszói pont 
arra valók, amire szólnak: az adott környezethez legyen 
egy lejátszó. Most inkább nézzünk körbe a többi között. 
Kedvenc apti tude-unkban egy kategória szerinti lista- 
ablakban (F10, Views, New Categorical Browser) a Sound 
and Music :: Compact Disks :: Players alatt keressünk. 

Az itt található programok közül a workman-workbone 
párost történelmi okokból érdemes kipróbálni. A workbone 
egy karakteres lejátszó, a workman pedig ennek egy grafi- 
kus felülettel ellátott változata. Mindenki válassza ki a neki 
megfelelőt. A saját kedvencem a cccd. 

Jó, jó, ezzel kipróbáltuk a CD nevű csatornát, de mivel pró- 
báljuk ki a PCM-et (a számítógép által létrehozott hangot)? 
Ehhez elég egy wav vagy MP3, vagy bármilyen egyéb, le- 
játszható szám. De honnan szedjen ilyet a tévelygő felhasz- 
náló? Például a hanglemezből is készíthetünk wav-fájlokat 
— erre a legtöbb lemezégető program lehetőséget ad. 
Lustább felhasználók kipróbálhatnak egy célprogramot is, 
mint amilyen a grip (ehhez Gnome kell), az mp3c (egy ka- 
rakteres program) vagy a ripperx. Ahogy írtam, az xmms is 
rendelkezik egy lemezre író kimeneti modullal, így például 
netes rádiókból is fel tudunk számokat venni. Rengeteg ne- 
tes rádiót találhatunk a $http:/www.shoutcast.com címen. 
Remek! Ennyi harci előképzettséggel műsorokat vehetsz fel 


netes rádiókból, majd kedvenc formátumodban tárolhatod 
őket vagy hanglemezt készíthetsz belőle (ehhez az xcdroast- 
ot ajánlom - a témára egy későbbi részben még bővebben 
kitérünk). Ha már a hangfájloknál tartunk, akkor egy hang- 
szerkesztő programot is érdemes ajánlanom. Rengeteg olyan 
wav-szerkesztő van, amelyet csak azért érdemes letölteni, 
hogy utána gyakorolhassuk a csomag eltávolítása lehetőséget. 
Van például olyan hangszerkesztő, amelyik úgy kezdi, hogy 
az egész wav-tájlt benyalja, elemzi, készít egy kivonatot, azon 
dolgozhatsz, majd a végén az eredményt lemezre írja. 
Remek! Flég, hogy felvegyél egy órányi anyagot a rádióból, 
amelynek eredménye egy 600 megás wav-fájl (nyers wav ese- 
tén nagyjából 10 megát számolhatunk egy percre), és egyből 
találkozol-e módszer nehézségeivel. Részemről a sweep-et 
ajánlom: könnyen és gyorsan használható, sőt szerkesztés 
közben még el is szórakozhatsz a nyikorgó hangokkal, amiket 
a fájlban mozogva hallhatsz. Mellesleg a swveep rendkívül sok 
átalakítást ajánl fel — ez a téma önmagában is nyugodtan 
megérdemelne néhány cikket. Itt jegyzem meg, hogy a linu- 
xos programokra oly jellemző módon erre is igaz, hogy készí- 
tőik a hatásokat (effects) többnyire úgy írták meg, hogy több 
szerkesztőprogramban is használhatók. Nem arról van tehát 
szó, hogy minden cég készít egy hangszerkesztőt néhány 
átalakítóval vagy hatással, és ha egy épeszű darabot akarsz 
összerakni, akkor négy-öt programot kell használnod (mind 
fizetős, és nos, valljuk be, lehet, hogy az egyiket hivatalosan is 
megvásároltad, de nem túl valószínű); hanem a programo- 
zóknak az a céljuk, hogy az általuk készített modulokat a fel- 
használók tényleg használni tudják. 

Pár bekezdés erejéig hadd térjek ki az MP3-mizériára. 
Ahogy írtam is: ha az ember nyers wav-fájlban, tömörítés 
nélkül kíván hanganyagot tárolni, átlagos, kétsávos (sztereó) 
módban, akkor percenként tíz megabájtot számolhat. Nagy- 
jából így jön ki, hogy egy lemezre egy kicsit több mint egy- 
órányi anyag fér fel (640 MB). Valójában a folyamatos hang- 
anyagban nagyon sok Zaj szerepel, amit az ember akár nem 
is hall, vagy ha hallja is, igazából csak bosszantja. Ha ezeket 
a zajokat kiszűrjük, a maradékot pedig (akár egy kevéssé 
gépigényes tömörítéssel) tömörítjük, akkor az eredmény egy 
szinte azonos minőségű fájl, de akár tizedakkora mérettel. 
Ilyen elmélet alapján született meg az MP3 (teljes nevén 
MPeg Audio Layer 3) tömörítés is. A hangot a tömörítések 
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4. kép A sweep 


általában folyamként kezelik, azaz olyan adattömegként, 
amennyiből egységnyi idő alatt valamennyi adatnak elő kell 
állnia. Így célszerűen az ilyen folyamok egyik fontos muta- 
tója, hogy milyen sávszélesség szükséges a hallgatásukhoz. 
Az MP3-as tömörítéssel például 64 bites szélesség mellett (ez 
nagyjából egy hétköznapi modem csúcssebessége) már él- 
vezhető sztereozenét lehet létrehozni. A 192-es már rendkí- 
vül jó minőségnek számít, a 256-os pedig szinte fehér holló. 
Ez az adatszélesség annyit jelent, hogy egy egységnyi hang- 
anyagot annyira kell tömöríteni, hogy , átférjen" egy ilyen 
átviteli vonalon. 

A dolog remekül is működik, de sajnos az MP3 tömörítés 
jogvédett. A jog birtokosa pedig szemfülesen nem kér jog- 
díjat minden MP3 formátumban tárolt fájl után, sőt a leját- 
szóprogramok után sem, csupán az MP3-akat előállító 
kódolók után. Ezért ha az emberfia MP3-fájlokat akar készí- 
teni, akkor vagy vásárol egy hivatalos kódolót, vagy jog- 
sértő tevékenységet végez. Ez a szabad programok követői 
számára természetesen nem volt elfogadható, így nekiáll- 
tak, hogy készítsenek egy szabadon használható kódolót, 
ami (ha már lúd, legyen kövér) tömörítsen jobban, szebben. 
Így készült az Ogg-Vorbis páros, ezt a formátumot lénye- 
gében ma már minden komolyabb lejátszó támogatja. 
Linux alatt olyannyira, hogy az , MP3-készítők" 
alapértelmezett formátuma az Ogg. Ha tehát van véletlenül 
MP3-kódoló a gépünkön, használhatjuk, viszont 
nyugodtan átállhatunk Ogg formátumra. Ráadásul, ha 
birtokában vagyunk a megfelelő kódolóknak, olyan 
formátumba alakítjuk zenéinket, amilyenbe akarjuk. 
Röviden végignéztük a hangkezelést, remélem, mindenki 
elboldogul ezen a területen, és bármikor el tudja végezni 

a szükséges alapfeladatokat, össze tud állítani egy neki 
tetsző hanglemezt, vagy éppen MP3-gyűjteményét tudja 
könnyedén gazdagítani, illetve mit is mondok! lermészete- 
sen Ogg-gyűjteményre gondoltam! Kellemes zenehallgatást! 


Szy György (Szy.GyorgyOlinuxvilag.hu) 
" A Linuxvilág főszerkesztője, 

[a Kiskapu Kiadó vezetője. 

Mindenki levelét örömmel várja. 
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A magyar Linux: UHUÚ 


A 2003. év nagy változást hozott a honi munkafelületek 
(desktop) és az Irodai (office) rendszerek piacán: megjelent 
a magyar fejlesztésű és nyelvű UHU Linux csomag, 





ami a hazai informatika több részterületén Is áttörést jelentett. 


ddigi előretörése egyenletes és folyamatos, sőt az 
a idei évet úgy nyitotta, hogy a Sulinet Expressz 

jóvoltából döbbenetes sebességgel ismertté vált. 
Hazánkban gyakorlatilag a második helyen áll a Linux- 
változatok gyakorisági listáján, és komolyan veszélyezteti 
a SuSE Linux vezető helyét. Ezért úgy gondoltam, ideje 
ezt a magyar fejlesztésű rendszert alaposabb vizsgálatnak 
alávetni, hiszen elterjedtsége és támogatottsága folya- 
matosan nő. Most induló cikksorozatunkban a felhasz- 
nálók számára a leghasznosabb és legérthetőbb formában 
igyekszünk kivesézni mindazt, amit az UHU Linuxról 
tudni érdemes. Sorozatunk első és második részében az 
általánosabb részekre térünk ki, ez a telepítési folyamatot, 
illetve a telepített és már működő rendszerünkben történő 
első felfedezőutunkat öleli fel. A későbbiekben a követ- 
kező főbb témaköröket tekintjük át: a multimédiát, az 
internetet és a hálózatokat, a grafikát, az irodai megoldá- 
sokat, és bizony, bizony, a játékokat is, mivel a Linux a 
szórakozásnak ezt a formáját is támogatja. 


Az URU Linux származása és alapjai 
Mielőtt telepítenénk a rendszert, érdemes megismerni 
néhány apróságot. Többek között azt is, hogy honnan 
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származik az UHU. A Linux-változatok két fő ágra oszt- 
hatók. A Debian Linux alapú rendszerekre, továbbá a Red 
Hat által bevezetett és azóta már de facto szabvánnyá vált 
Red Hat alapú megoldásokra. Jellemzően (származási 
ágtól függően) mindkét megoldás egy-egy csomagkezelési 
elvre épül, ez pedig a .rpm (Red Hat Package Manager), 
illetve a .deb (Debian). A linuxosok egymás között mind- 
ezt tömören csak rpm alapú vagy deb alapú rendszerek- 
nek hívják. Az UHU Linux a hagyományosnak tekinthető 
.deb elvet követi azzal a különbséggel, hogy egy kicsit 
javítottak rajta és megalkották a , dpkg" elvet, amelynek 
jellemző kiterjesztése a .uhu lehet. Ez azzal a veszély- 

lyel járt együtt, hogy a .uhu csomagok szerényebb száma 
kedvezőtlen hatással lehet a rendszer elterjedésére, mivel 
ehhez külön .uhu csomagokat kell már meglévő .rpm, 
illetve .deb csomagokból előállítani. Nos, nagyszámú 
önkéntes gondoskodott róla, hogy ez a nehézség ne 
okozzon fennakadást, és az UHU Linux-csapat vállalta, 
hogy ezeket az önkénteseket folyamatosan megtanítják 

. uhu csomagokat készíteni. Mint a későbbiekben látni 
fogjuk, a feladatot briliánsan megoldották, így igen 
nagyszámú - és a külön eljárásból következően — meg- 
bízható, ellenőrzött, és biztonságosan használható 
csomagok árasztották el honlapok tucatjait. 


Gépigény 

Az UHU Linuxszal kapcsolatos kérdések között nagyon 
sokszor szerepel, hogy ,mégis, mekkora a gépigénye?" . 
Erre maga a válasz is egy kérdés: milyen feladatra szeret- 
nénk használni? A közhiedelemmel ellentétben ugyanis 
egy linuxos munkaállomás is használható játékgépnek. 
Kifogástalanul fut rajta a Ouake, az Unreal, a Freespace, 
a Wolfenstein-sorozat összes jeles tagja, stratégiai játékok 
garmadája (Heroes3, MythII stb.), valamint a kisebb 
játékok százai. Értelemszerűen azonban ezeknek a gép- 
igénye lényegesen nagyobb, sőt a többszöröse lehet 
például egy szövegszerkesztő erőforrásigényének. Ha 
pontosítom a választ, akkor azt lehet mondani, hogy a 
processzor legalább 300 MHz-es Celeron legyen, és habár 
64 MB memórián is jól használható, érdemes 128 MB-nyit 


alátenni. A teljes telepítés (amelynek során az első CD-ről 
mindent felteszünk -— célszerű is így cselekedni) 1,9 GB 
helyet foglal el a merevlemezről, és ehhez természetesen 
hozzá kell tenni a feltétlenül szükséges csereterületet 
(swap), amelyet külön lemezrészre (partition) kell helyez- 
nünk. Ezzel a gépkiépítéssel az UHU már olyan módon 
telepíthető, hogy zenelejátszásra és irodai műveletek 
elvégzésére egyaránt alkalmas, teljesen emberi sebesség- 
gel. Értelemszerűen a több erőforrás jobb, játékok eseté- 
ben pedig egyenesen követelmény ennek a kiépítésnek 
akár a többszöröse is. (Nem kell ecsetelnem, hogy az 
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Unreal Iournament 2003 erőforrásigénye mekkora, hiába 
fut sokkal jobban Linuxon, mint más rendszereken.) 
Érdemes azt is megjegyezni, hogy az UHU Linux nem 
,eszi" az erőforrást, ugyanakkor jellemzően követi a 
linuxos elvet, amely szerint az üresen hagyott erőforrás 
rossz erőforrás. Mindez az eszközök lehető legjobb 
kihasználása végett van így, de létezik olyan, manapság 
már nem meglepő méretű erőforrással rendelkező kiépí- 
tés, anely már nem képes a lehetőségeket teljesen kiak- 
názni, hiszen meghaladja az UHU teljes erőforrásigényét, 
akár több feladat egyidejű elvégzése esetén is. Lássunk 
egy példát: az én gépem egy 800 MHz-es Duron pro- 
cesszort tartalmaz 512 MB DDR memória kíséretében. 
Ezzel a kiépítéssel csereterületet szinte nem is használ, még 
a játékok alatt sem. Gyakorlatilag sokkal több erőforrás áll 
rendelkezésre, mint amennyi szükséges, ezért ezen a gépen 
bámulatosan gyorsan fut az UHU. 


A telepítés fontosabb állomásai 

A telepítése gyakorlatilag gyerekjáték. Nem térek ki a teljes 
telepítésre, aminek több oka is van: először is rendkívül 
beszédes a telepítő, teljesen egyértelmű, hogy mit miért kell 
tennünk. Ha egy külön merevlemezt szánunk az UHU-nak, 
szinte nem is kell más gombot megnyomni, mint az Ok-t. 

A másik ok, amiért nem részletezem a folyamat állomásait, 
az az, hogy a második korongon a teljes UHU Linux-füzet 
PDF formátumban megtalálható, s ez több fejezetnyi 
szöveget és képet tartalmaz ezzel kapcsolatban. Ennek a 
füzetnek (és a könyvnek, mivel az még tartalmasabb) a 
frissített változatai megtalálhatóak az 3 ítp.uhulinux.hu 
kiszolgálón, s innen könnyedén letölthetők. Sőt ugyanitt 
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megjelent a jókora , Nagy UHU Linux könyv" is. 

Így most csak az olyan kényes pontokra térnék ki, amelyek 
a legtöbb kérdést vethetik fel. Az első ilyen a lemezrészre 
osztás folyamata. Ha ,más" rendszer is van a gépen (és jó 
hazai szokás szerint mindezt egyetlen lemezrész tartal- 
mazza), akkor egy lemezfelosztó program szükséges, amely 
képes lemezterületet elvonni a Linux számára. Minderre az 
egyik legjobb választás a Partition Magic program, amellyel 
az egész könnyedén megoldható; vagy ha FAT fájlrend- 
szerű a kezelendő lemezrész típusa, akkor az UHU első 
CD-jének DOS könyvtárában megtaláljuk a Fips nevű apró 
és ingyenes segédprogramot, amely ugyanezt pillanatok 
alatt képes elvégezni. Ne ijedjünk meg attól, hogy piciny 
DOS-os segédprogramról van szó, mert könnyen kezelhető 
és hibátlanul végzi el a feladatát. 

Érdemes kitérni arra is, hogy mekkora legyen ez a lemez- 
rész. Nos, két linuxos lemezrészre lesz szükségünk. 

Az egyik a csereterület, a másik a Linux, amely magát 

a rendszert fogja tartalmazni. (Az elvont lemezterület fel- 
osztásánál, ha lehet, először a csereterületet készítsük el.) 
A csereterület méretére létezik egy nem teljesen szent 
szabály, inkább ajánlás, ami a következő: 16, 32, 64, 128 
MB fizikai memória esetén a csereterület mérete legyen a 
fizikai memória kétszerese (tehát 128 MB esetén 256 MB). 
Ha azonban 256 MB vagy afölötti memória áll rendelke- 
zésre, célszerű egy ezzel megegyező méretű virtuális 
csereterületet létrehozni. Azt is szokták mondani, hogy 
512 MB memória esetén már nem is szükséges csereterü- 
letet létrehozni. Én viszont amondó vagyok, hogy ekkor 
is hozzunk létre 256 MB-ot, jól jöhet, ha nagyon megter- 
heljük a gépünket, és lassítani semmiképpen sem fogja, 
legfeljebb üres marad. 

lovábbi fontos szempont, hogy a csereterület fájl is lehet, 
de biztosabb módszer, ha lehetőleg a lemez elején, egy 
külön lemezrészen helyezkedik el. (A lemez elején kisebb 
a hozzáférési idő, mint a végén, tehát hatással van a 
sebességre.) Vagyis a telepítés előtt már a linuxos lemez- 
részek elkészítésekor érdemes figyelembe venni és végig- 
gondolni a csereterület méretét, és ennek megfelelően 
készíteni el számára a lemezrészt. 

A másik gyakori kérdés az, hogy mikért telepítsünk, ha 

a gépünket nem tudjuk CD-ről indítani? Az első telepítő 
CD-nek szintén a DOS könyvtárában található a rawrite 
DOS-os segédprogram, amely lemezlenyomatfájlokat 
(image) hivatott hajlékonylemezre helyezni. Az ehhez 
tartozó lemezlenyomatfáj! az első CD IMAGES könyvtárá- 
ban található uhuboot.img néven. Ezzel a megoldással 
hajlékonylemezről is indítani tudjuk a gépünket és telepít- 
hetjük az UHU Linuxot. 

A következő meglepetés viszont a régebbi gépek tulajdono- 
sainak szokott fejfájást okozni. Ha gépünk nem rendelkezik 
PS/2 egérrel, csak régebbi sorossal, akkor könnyen meg- 
eshet, hogy az UHU nem ismeri fel. (Ez azonban csak az 
1.0-sra vonatkozik, a cikk írásakor éppen kiadás előtt álló 
1.1-esben már nincs benne ez a hiba). Ebben az esetben 
kézzel kell beállítanunk az egerünket. 

A telepítés során a harmadik említésre méltó lépés, hogy 
a telepítés végeztével a rendszerbetöltőt valahová el kell 
helyeznünk. Miután bekapcsoltuk a gépet, a rendszerbe- 
töltő fogja elindítani a Linuxot; a telepítő több helyre is 
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felajánlja a felrakását. Löbb fizikai lemez esetén még azt 

is eldönthetjük, hogy melyik lemezen helyezzük el. Ha 
egyetlen lemezünk van (vagy több lemez esetén az első 
lemezre telepítettünk), akkor célszerű az , ajánlott" pontot 
kiválasztani, így a telepítő a rendszerbetöltőt közvetlenül 
a lemez elejére, a merevlemez rendszerindító területére 
(Master Boot Record, MBR) rakja. Ha ,más" rendszer is ott 
csücsül a lemezen, akkor is ez a teendő, mert a telepítő 
intelligensen felismeri, hogy más rendszer is van a gépen, 
és ennek megfelelően írja meg a rendszerbetöltő bejegy- 
zéseit. lovábbá fontos lehet a rendszerbetöltő milyensége. 
A szakkönyvek általában a LILO-ról (LInux LOader) 
írnak, talán csak a legfrissebbek jelentenek ez alól kivételt. 
Valóban, sokáig a LILO felelt a Linux betöltéséért, ezért 

a szakkönyvek is ezt ismertették bővebben és az interne- 
ten is erről találjuk a legtöbb leírást. Az UHU a korszerűbb 
és rugalmasabb GRUB rendszertöltőt használja, amelyre 

a második korong kézikönyve is kitér, valamint a 

2 http:/www.uhulinux.hu weboldalon is olvashatunk ró- 
la. Ha nem tudjuk, mi a teendő és tanácstalanok vagyunk, 


stk 


célszerű a telepítő által ajánlott megoldást elfogadni. 


Az első felfedezőút és az utolsó simítások 
A telepítést követően a rendszer azonnal , kulcsrakész", 
tehát semmiféle teendőnk nincsen. Gyakorlatilag egyszer 


Fája egni sánt árát ágyerű mása) 
va EE emétaretarási vieéttáésása 
Ég ür kajzőszáeli fra 


búrul agpüljú ran 
ÉrEz Lzérásd 
TELEN tareTTNTE I 


HAT NN LAF HA 
klmmTZERI th 
li Poe aláz resdőldi ebb eánésteátük 
] Femfkztel i 
Fr areérmáu d 
- Eereába hl ret EBET Írt ir 1] 


sem kell újraindítani a számítógépet, minden átgondolt, 
gördülékeny. A rendszer betöltődése után mindig be kell 
jelentkezni: a telepítés során létrehozott felhasználói névvel 
és jelszóval tudunk felhasználóként belépni. Ezután el 
tudjuk végezni az utolsó simításokat: a hálózati kapcsolatok 
kialakítását, a nyomtató hozzáadását és számos egyéb 
művelet is. Indítsuk el az UHU Vezérlőpult programot, ami 
a menüben található. Írjuk be a telepítés során megadott 
rendszergazdai jelszót (kérni is fogja). 

A Vezérlőpult használata is igen egyértelmű, sőt soroza- 
tunkban sokat fogunk rá hivatkozni. Most inkább azt 
tekintsük át, hogy az első indítás után mit érdemes 
elintézni. Az UHU alapértelmezett ablakkezelője a Gnome, 
bár a KDE sokkal népszerűbb. Igaz, bejelentkezéskor 
megváltoztathatjuk az ablakkezelőt, de ha a KDE 
bejelentkezéskezelőjét szeretnénk (kdm), akkor a 
Vezérlőpultban tudjuk beállítani. A Szolgáltatások részben 
keressük ki a gdm bejegyzést, és nyomjuk meg a ne 
induljon el gombot. Ha megkérdezi, hogy most leállítsa-e 
a gdm-et, akkor a válaszunk nem. Ezután keressük ki 

a kdm bejegyzést, és nála nyomjuk meg az elinduljon 
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gombot. Meg fogja kérdezni, hogy elindítsa-e a kdm-et; a 
válaszunk szintén nem. Az új beállítás érvényesítéséhez 
lépjünk ki a bejelentkezőképernyőhöz és indítsuk újra a 
grafikus felületet. Ezt az ALr-4I vagy az ALT-E billentyű- 
paranccsal tehetjük meg, attól függően, hogy feltettük-e 
a frissítéseket vagy sem. 

Amennyiben a hálózati kártyánkat (ha az interneteléréshez 
szükséges) és a DNS-adatokat (szintén a Vezérlőpultban) 
beállítottuk, akkor elindíthatjuk az UIHU tárcsázó segéd- 
programot, amellyel internetkapcsolatunkat felépíthetjük. 
Jópofa lehetőség, hogyha a tárcsázóval ADSL kapcsolatot 
építettünk fel, akkor az UHU Vezérlőpult / Szolgáltatások 
részében önműködővé tehetjük a feladatot. Itt keressük 
ki az adsl/adsl indítása bejegyzést, és kattintsunk az 
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,elinduljon" gombra. Ezután bármikor, amikor elindítjuk 
a gépünket, a rendszer betöltődése során az ADSL kapcso- 
latot is felépíti, így többet nem kell vele foglalkoznunk. 


Grafikus felület és adatok 

Szükségünk lehet rá, hogy a KDE felületet beállítsuk, 
esetleg részletesebb adatokat kérjünk a rendszerről. 

Az előbbit a KDE Vezérlőpultjával tudjuk megtenni, ahol 
beállítható a háttérkép, a betűk, az ablakok stílusa, sőt 

akár külön témákat is telepíthetünk, ahogyan azt más rend- 
szerek alatt már megszokhattuk. 

Ebben a Vezérlőpult-ban a Webböngészés menüpont alatt 
állíthatjuk be, hogy a KDE alapértelmezett böngészője, 

a Kongueror hogyan is viszonyuljon az internetes adatok- 
hoz. Például nagyon hasznos tulajdonsága, hogy a süti- 
kezelést (cookie) finomhangolni vagy tiltani tudjuk. 
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A felugró ablakokat letilthatjuk és mind a Java-, mind 

a JavaScript-adatokat teljesen kizárhatjuk. Szigorú 
szabályozással biztonságosabbá és erőforrás-kímélőbbé 
tudjuk tenni az internetes böngészést. (Biztosan min- 
denki találkozott már bosszantó felugró ablakocskákkal 
vagy egy-egy weboldalon túl sok JavaScripttel, ami 
jelentősen lelassította a rendszerét.) 

Itt találhatók a KDE alapvető hangbeállításai, sőt a nyomta- 
tóbeállításokat is módosítani tudjuk a Perifériák menüpont- 
ban - ennek segítségével hálózati nyomtatót is önműködően 
keresni tudunk. Alapvető biztonsági és energiakezelési beál- 
lításokra is lehetőség nyílik, amelyek rendkívül kényelmes és 
hasznos eszközök a gép ínomhangolása során. A beállítások 
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elvégzéséhez pedig a KDE Menü/Rendszer menüpontja alatt 
található KinfoCenter szolgáltathat adatokat, ahol rendkívül 

részletesen láthatóak az egyes eszközök, a memóriacímek és 
minden egyéb, amire szükségünk lehet. Hasznosságát nem 

kell ecsetelnem, ha esetleg egy nem együttműködő (incom- 

patibility) eszközt szeretnénk a rendszerbe beleilleszteni. 


Összegzés 

Tömören, pusztán a lényegre szorítkozva átvettük, 
hogy milyen terjesztés az UHU Linux, megvizsgáltuk 

a gépigényét és a telepítés során felmerülő esetleges 
buktatókat, valamint rövid körútra indultunk a frissen 
telepített rendszerben. Megnéztük, hogy mire is hasz- 
nálható a Vezérlőközpont és hogyan kaphatunk részletes 
adatokat a rendszerről. lIovábbá megemlítettük, hogy 
hogyan és hol érdemes elvégezni néhány alapvető beál- 
lítást. A következő hónapban áttekintünk pár parancsot 
a konzolos használathoz, telepítünk egy nVidia video- 
kártyát, kitérünk a rendszerífrissítés alapjaira, valamint 
a KPackage használatának segítségével átvesszük a 
csomagkezelést. Végül telepítünk egy játékot, hogy 
olvasóinkat játszani is engedjük. 


Dancsok , strogg" Zoltán (stroggomail.tvnet.hu) 
.] Jelenleg technikai szerkesztőként dolgozik a 
Il BME-OMIKK-nál, ahol oktat Is. Emellett egyetemi 


képzésben vesz részt, programozó matematikus sza- 


kon. Négy éve foglalkozik Linuxszal. Szabadidejében 
operációs rendszereket gyűjt és weblapot vezet. 
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Hálózatok: 


Sorozatunk előző 


a TCP/IP hivatkozási modell (3. rész) 


részében megismerkedtünk a hivatkozási modellekkel, illetve 


egyik képviselőjükkel, az OSI modellel. Most a TCP/IP modellel foglalkozunk. 


ikksorozatunk előző részében az OSI hivatkozási 
5 modellt mutattuk be, amit a gyakorlatban ugyan 

sehol sem használnak, mégis nagyon fontos abból 
a szempontból, hogy szétválasztja a szolgálat, a csatoló- 
felület (interface) és a protokoll fogalmát. Mivel sorozatunk 
erre a három fogalomra épül, nem árt, ha gyorsan feleleve- 
nítjük, mit is jelentenek. 
A szolgálat azt határozza meg, hogy az adott rétegnek pon- 
tosan mi is a feladata. Ez azt jelenti, hogy a szolgálat nem 
más, mint olyan elemi műveletek halmaza, amelyet a felső 
réteg bármikor elvégeztethet vele. Szeretnénk hangsúlyozni, 
hogy a szolgálat csupán ezeket a műveleteket sorolja fel. 
Arról azonban, hogy miként hívhatjuk őket meg, illetve hogy 
az adott feladatot hogyan valósítja meg, mélyen hallgat. 
A csatolófelület a szolgálatok elérésének szabályait mondja 
meg. Ilyen szabályok lehetnek például, hogy milyen érté- 
keket kell átadni, illetve hogy az adott művelet elvégzése 
után milyen lehetséges eredményeket kaphatunk vissza. 
A csatolófelület sem árul el semmit a gyakorlati megvalósí- 
tásról, így ez teljesen rejtve marad a felső rétegek előtt. 
A gyakorlati megvalósítás módja a réteg által használt 
protokolltól függ. Nagyon fontos, hogy az OSI modellben 
szabadon megválaszthatjuk a használni kívánt protokollt, 
mivel annak változása nem befolyásolja a csatolófelületet, 
illetve magát a szolgálatot. (Ez az egész nagyon hasonlít az 
objektumközpontú programozáshoz: a rétegek egy-egy 
objektumnak felelnek meg, a szolgálat az adott objektum- 
ban található eljárások összessége. A csatolófelület az eljá- 
rások értéklistája, illetve a visszatérési értékek típusa; a 
protokoll pedig az eljárások törzse, amely teljesen láthatat- 
lan a külső szemlélő számára). 


A TCP/IP hivatkozási modell 


A TCP/IP hivatkozási modell képezi az alapját egy világmé- 
retű hálózatnak, amelyet mi már csak internet néven emle- 
getünk. Ez a modell bizonyos szempontból nagyon hasonlít 
az OSI-ra, de el is tér tőle. Minderről egy kicsit később szólok, 
először nézzük meg a modell kialakulásának a körülményeit! 
Az OSI modellhez hasonlóan a ICP/IP is rétegekből áll, de 
csak négy darabból épül fel (lásd az 1. ábrát) — az alsó két 
réteg ugyanis , összevontan" van jelen, a viszony- és a 
megjelenítési réteg pedig nem szerepel a modellben. 
Legalul a gép és hálózat közötti réteg található. Érdekes mó- 
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alkalmazási réteg 


szállítási réteg 


internetréteg 


gép és hálózat 
közötti réteg 


TCP/IP hivatkozási modell 


OSI hivatkozási modell 


1. ábra Az OSI és a ICP/IP hivatkozási modell összehasonlítása 


don erről a ICP/IP nem mond semmit, csak azt, hogy itt egy 
úgynevezett IP-csomagokat továbbítani képes protokollnak 
kell szerepelnie. Az sincs megkötve, hogy ennek a proto- 
kollnak mindenhol ugyanolyannak kell lennie — ez hálóza- 
tonként, illetve gépenként is változhat. Mi most ezzel a 
réteggel nem is foglalkozunk, mivel hivatalosan nem tartozik 
a ICP/IP-hez, de a következő részben visszatérünk rá, amikor 
az adatok fizikai átvitelével kapcsolatos kérdéseket tárgyaljuk. 
A modellben szereplő legalsó réteg az internetréteg. Fela- 
data ,csupán" annyi lenne, hogy a csomagokat eljuttassa 
egyik helyről a másikra. Valójában ez egy rendkívül össze- 
tett feladat, mivel a célállomás általában nem ugyanannak 
a hálózatnak a része, mint ahonnan mi küldjük a csoma- 
gokat. Lehet, hogy a célpont egy másik földrészen helyez- 
kedik el és rengeteg más hálózaton kell keresztüljuttatnunk 
a csomagokat. 

Fontos, hogy a TCP/IP modell rétegei sem árulják el, hogy 
miként dolgoznak. A felső rétegeknek csak át kell adniuk 

a csomagot az internetrétegnek, anélkül, hogy bele kellene 
gondolniuk, hogy miként jut el a csomag a kívánt helyre. 


Ez olyasmi, mint a hagyományos postai levelezés. Nekünk 
csak be kell dobnunk a megcímzett borítékot a postaládába 
— innentől kezdve a levél sorsa a postára lett bízva. Mi és a 
levelezőpartnerünk csak annyit veszünk észre, hogy a bedo- 
bott levél pár napon belül a címzett postaládájába érkezik. 
Arra pedig csak következtetni tudunk, hogy mindeközben 

a levél hány postahivatalon és központon ment keresztül. 
Az internetréteg protokollját Internet Protocolnak, röviden 
IP-nek nevezzük. Mivel itt a csomagok sikeres célba jutta- 
tása a legfontosabb feladat, ezért az IP a leghatékonyabb 
útvonal kiválasztásával, illetve a , forgalmi dugók" elkerü- 
lésével foglalkozik. 

A TCP/IP hivatkozási modell következő rétege a szállítási 
réteg, amely gyakorlatilag megegyezik az OSI-féle szállítási 
réteggel. Ez teszi lehetővé a kapcsolatban résztvevő két fél 
(pontosabban a társentitások) párbeszédét. Ez a réteg két- 
féle protokollt használhat: a megbízható ICPt-t és a kevésbé 
megbízható UDP-t. 

Ennek a modellnek az IP mellett a TCP (Iransmission 
Control Protocol, azaz átvitelvezérlő protokoll) a második 
legjelentősebb protokollja, ami egy hibamentes átvitelt 
biztosító, összeköttetés alapú protokoll. Az átvitel bájtos 
formában történik, azaz a réteghez beérkező bájtfolyamot 
előre meghatározott méretű üzenetekre bontja, és ezeket 
továbbítja az internetrétegnek. A célállomáson ennek a 
fordítottja zajlik: az internetrétegtől kapott üzeneteket 
egyetlen bájttolyammá fűzi össze. 

Ahhoz, hogy mindez megvalósuljon, a ICP-nek forgalom- 
irányításra is képesnek kell lennie. Ez annyit tesz, hogy az 
üzeneteket legfeljebb olyan sebességgel adagolja, ahogy azt 
a vevő fogni képes. Enélkül a gyorsabb gépek könnyen 
eláraszthatják üzenetekkel a lassabbakat, teljesen használ- 
hatatlanná téve őket. 

A réteg másik protokollja az UDP (User datagram Protocol), 
amely a ICP-vel ellentétben nem összeköttetés alapú, 
továbbá teljesen megbízhatatlan. Mégis nagy jelentősséggel 
bír akkor, ha sokkal fontosabb a gyors, mint a pontos válasz. 
Gondoljunk csak a hálózaton keresztüli hang- és képátvitel- 
re: a felhasználókat kevésbé zavarja, ha egy-két pixel hibá- 
san ér át, mintha a lejátszás során végig akadozna az anyag. 
A legutolsó réteg az alkalmazási réteg, ahová a magsabb 
szintű, a felhasználók által is használt protokollok tartoz- 
nak; ilyen például a fájlátvitelre alkalmas FTB a levelezésre 
használt SMIP a virtuális terminál (TELNET) és a névfelol- 
dásért felelős DNS. Ide tartozik még a webböngészők és 
kiszolgálók között használt protokoll, a HITP is. Ezek 
működésével sorozatunk befejező részeiben részletesen is 
megismerkedünk. 


Gondok a TCP/IP-vel 


A mai világban a TCP/IP protokolljait használják a leggyak- 
rabban, ami mégsem jelenti azt, hogy ez a modell tökéletes 
lenne. Kezdjük azzal, hogy a TCP/IP hivatkozási modell 
eleve nem választja el szembetűnően a szolgálat, a csatoló- 
felület és a protokoll fogalmát; erre a későbbiekben egy 
példa során rá is fogunk mutatni. A későbbiekben látni 
fogjuk, hogy nagyon nehéz megállapítani, hogy mi tartozik 
a szabványhoz és mi a megvalósításhoz. Ezzel szemben az 
OSI modell nagy gondot fordít arra, hogy ez a két dolog 
egyértelműen megkülönböztethető legyen. 
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A modellel kapcsolatos másik gond az, hogy nem általáno- 
sítható. Ez azt jelenti, hogy ha ez alapján kéne megtervez- 
nünk egy hálózatot, viszont nem a ICP és az IP protokol- 
lokat szeretnénk használni, elég nehéz dolgunk lenne. 
Megfordítva: ez a modell csak a ICP/IP protokollkészlethez 
alkalmazkodik. 

Mindemellett a TCP/IP hiányos modell, mivel nem foglal- 
kozik az adatátvitel fizikai megvalósításával. Nemcsak hogy 
nem különbözteti meg a fizikai és az adatkapcsolati rétege- 
ket, de meg sem említi őket. Egyszerűen csak egy csatoló- 
felületet ad hozzá, és azt mondja, hogy itt egy olyan valami 
legyen, ami ezt és ezt a csomagot eljutattja ehhez és ehhez 
a hálózati ponthoz. Ez azért gond, mert a hálózati és az 
adatkapcsolati réteg alapvetően két különböző dologért 
felelős. A hálózati réteg az adatokat az egyik géptől a másik 
(szomszédos) gépig juttatja el, például vezetéken vagy 
rádióhullámok, esetleg fényjelek segítségével. A hálózati 
réteg számára azonban minden adat csak egy bitsorozat. 
Az adatkapcsolati réteg ezzel szemben már keretekkel 
működik (lásd az előző részt), azaz gondoskodik arról, 
hogy az átküldött bitsorozat szétválasztható legyen. Ezen- 
kívül különböző hibajavító kódokkal is dolgozik, amelyek 
a hibátlan átvitelt biztosítják. 

Az IP és a ICP szerencsére jól átgondolt és remekül 
működő protokoll, a többire ez azonban már nem teljesen 
igaz. Ezek közül a legtöbbet olyan módon írtak meg, hogy 
mindenféle átgondolás vagy tervezés nélkül egyszerűen 
belevágtak. Emiatt azoknak, akik később meg akarták fej- 
teni a működésüket, éjszakákon át a megvalósításban kel- 
lett molyolniuk. A megértésre azonban nem is volt mindig 
szükség, mivel a megvalósítások ingyenesek voltak, s így 
semmi sem akadályozta meg, hogy ezeket a protokollokat 
beépítsék az operációs rendszerek legbelső részébe. Ezáltal 
rendkívül nehézkessé vált a továbbfejlesztésük, illetve a 
lecserélésük. Ez megmagyarázza azt is, hogy a körülbelül 
negyed évszázaddal ezelőtt született TELNET protokoll 

-— amely sem az egér, sem a grafikus felület kezelésére nem 
képes — miért lehet máig is elfogadott (habár ma már 
inkább , titkosított változatát", az ssh-t használják). 

Ebből az egészből tulajdonképpen csak egy tanulságot 
vonhatunk le: míg az OSI modellel rendkívül egyszerűen 
és tanulságosan írhatjuk le a mai hálózatok működését, 
addig a ICP/IP erre nem igazán alkalmas. Az OSI modell 
protokolljainak megvalósítása azonban rendkívül nehéz, 
így a való életben nem is váltak népszerűvé. A TCP/IP 
protokollokat széles körben használják, viszont a TCP/IP 
mint hivatkozási modell valójában semmire sem használ- 
ható, mivel nem ad teljes elméleti leírást a hálózatokról. 


Az internet és a TCP/IP kapcsolata 

Az internet eredete körülbelül a 60-as évek közepéig nyúlik 
vissza. A legismertebb történet szerint az internet egy 
katonai célokra, pontosabban egy atomtámadás túlélésére 
,kiképzett" hálózatból fejlődött ki. Ez részben igaz is, és a 
dologhoz valóban elég sok köze volt az amerikai védelmi 
minisztériumnak, ám a valóság — mint mindig - ennél 
sokkal árnyaltabb. 

Abban az időben három különálló intézmény is ugyanazon 
a feladaton, a csomagkapcsolt hálózatok létrehozásán 
fáradozott anélkül, hogy bármit is tudtak volna egymásról. 
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2. ábra A kezdeti ARPANET hálózat 


Ezek közül csak az egyik, a Rand Corporation által vezetett 
kutatások voltak katonai indíttatásúak. Ennek az a törté- 
nete, hogy az amerikai védelmi minisztérium úgy gondolta, 
hogy egy atomtámadás esetén az akkori vonalkapcsolt 
távbeszélőrendszer összeomlana, így létre kellene hozni 
egy másik, az ország távoli pontjait összekötő hálózatot, 
amelyen továbbíthatnák a parancsokat. 

A minisztérium ezért kutatási részlegükhöz, az ARPA-hoz 
fordult. Ez egy meglehetősen érdekes intézmény volt, azért 
hozták létre, hogy valamennyire kiegyensúlyozzák az 
akkori Szovjetuniónak az űrkutatás területén megszerzett 
fölényét. Ugyanakkor az ARPA-hoz nem tartoztak sem 
tudósok, sem laboratóriumok; úgy működött, hogy ösztön- 
díjakat és szerződéseket kínált fel egyetemek, illetve cégek 
számára, és kutatási eredményeiket megpróbálták hasz- 
nosítani a haditechnika terén. Így került képbe a Berkeley 
Egyetem és a Rand Corporation is, ahol számos olyan 
ember dolgozott, aki meg volt győződve róla, hogy a cso- 
magkapcsolás lehet a feladat megoldása. 

A csomagkapcsolás akkoriban eléggé forradalmi ötletnek 
számított. A kiinduló elgondolás az volt, hogy az elküldeni 
kívánt üzenetet csomagokra kell bontani. Minden csomag 
tartalmazta az útvonalválasztáshoz szükséges adatokat is, 
illetve azokat a dolgokat, amelyek a hibák felismeréséhez 
és kijavításához szükségesek voltak. 

Ezzel a témával a Randon kívül a Massachusetts Institute 
of lechnology (MIT) és a brit National Physical Laboratory 
is foglalkozott. A három kutatócsoport először 1967-ben 
találkozott egymással, ekkor hozták létre az ARPANEI-re 
keresztelt hálózat első tervét (2. ábra). A gépeket összekötő 
alhálózat úgynevezett csomóponti gépekből állt. Minden 
ilyen gép legalább másik kettőhöz csatlakozott, hogyha egy 
csomópont esetleg ki is esne, a csomagok akkor is célba 
érjenek -— igaz, más útvonalon. 

A terv bemutatása után a megvalósítás céljára az ARPA 
pályázatokat írt ki, amit a BBN nevű cég meg is nyert. 

Ők telepítették az első csomópontokat, illetve írták meg 

a hálózati programot. Az ARPANEI 1969-ben indult útjára 
egy NCP (Network Control Protocol) nevű protokollal, 
amely a ICP elődjének számít. 

Az ARPANEI hamar népszerű lett; a sikere egyrészt annak 
tudható be, hogy a kiépítés nyílt volt, azaz független háló- 
zatokból épült fel, amelyek az ARPANET-en belül 
egyenrangúak voltak egymással. Az idő előrehaladtával 
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egyre több hálózatot kapcsoltak be az ARPANEI-be. 

Az NCP-nek azonban két súlyos hibája is akadt: nem lehe- 
tett a somópontok mögé címezni és csomagvesztés esetén 
a protokollok általában lefagytak. Ezért Kahn és Cerf javas- 
latott tett egy új protokoll létrehozására, amelyet TCP-nek 
neveztek. (Ez még nem a jelenleg használatos TCP hanem 
a ICP/IP egyfajta elődje volt). Az új protokoll tervezésekor 
alapvető szempont lett az, hogy egy új hálózat bekapcso- 
lásakor ne kelljen magát a hálózatot módosítani. Fontos 
volt az is, hogy a hálózat ne igényeljen globális ellenőrzést, 
így a hálózatnak nem kellett törődnie azzal, hogy a csoma- 
gok célbaérnek-e vagy sem. Ezzel csak a kapcsolatban 
közreműködő két félnek volt gondja: ha nem érkezett meg 
a várt csomag, újból el kellett küldeni. 

Mivel a ICP-t nem a legalsó szintre valósították meg, fájl- 
átvitelre vagy távoli gépekre való bejelentkezésre könnyen 
igénybe lehetett venni. Ugyanakkor alkalmatlan volt olyan 
feladatokra, ahol inkább a kapcsolat sebesssége volt a fontos, 
semmint az, hogy a hálózaton elvesztett összes csomagot 
pótoljuk. Ilyen feladat volt például a beszédátvitel. Ezért a 
ICPt-t két részre osztották: a ICPt-re és az IP-re; a régi TCP-t 
tehát e két szétválasztott protokoll kettőse, a TCP/IP adja. 

A Berkeley egyetem munkatársai eközben egy kényelmes 
csatolófelületet fejlesztettek ki, amely a foglalat (socket) fo- 
galmára épül (erről részletesen a későbbi részek során lesz 
szó). Ehhez nagyszámú felhasználói alkalmazást is készí- 
tettek, amelyek megkönnyítették az ARPANE! használatát. 
Ez a későbbiekben jelentősen hozzájártult az ARPANET 
sikereihez, mivel az egyetemek egynél akkoriban kezdtek 
el több számítógépet is működtetni. Többnyire VAX-okat 
vettek és egyből ki is építették hozzájuk a helyi hálózatu- 
kat. A gond az volt, hogy akkoriban nem volt olyan operá- 
ciós rendszer, amely a hálózati feladatokat is elláthatta 
volna. Szerencsére pont ekkor jelent meg a 4.2 BSD, amely 
elsőként tartalmazta a TCP/IP megvalósítását. Ezek mellett 
tartalmazta a foglalatokat és több tucat hálózati segédprog- 
ramot. Az egyetemeknek ez kapóra jött, és mivel a 
TCP/IP-vel könnyedén lehetett a helyi hálózatot (LAN) 

az ARPANETI-hez kapcsolni, ezt sokan meg is tették. 

1983. január 1-jétől az ARPANET hivatalos protokollja 
tehát a TCP/IP lett, és egyre több helyi hálózat csatlakozott 
hozzá. Mivel egyre több gép volt, szükségessé vált a DNS 
(Domain Naming System) kifejlesztése, amely lehetővé 
tette, hogy a gépeket ne csak IP-cím, hanem nevek alapján 
is el lehessen érni. 

Eközben a védelmi minisztérium az ARPANET-ről leválasz- 
totta a katonai hálózatokat, és számukra egy különálló, zárt 
hálózatot hozott létre, ez volt a MILNET. Akkoriban ez a 
lépés csaknem a gépek felének a leválasztását jelentette. Az 
ARPANET-et a 80-as évek közepétől már internetként (mint 
hálózatokat összekötő hálózatot) tartották számon. 

A következő résztől elkezdünk a fizikai réteggel foglalkozni, 
azaz megismerjük az adatátvitel elméletét és gyakorlatát. 


Garzó András (garzoandXinterware.hu) 

Körülbelül három éve foglalkozik Linux- és más Unix-rendsze- 
rekkel. Legjobban az operációs rendszerek lelkivilága érdekli, 
de nyitott egyéniség. Kedvenc étele a palacsinta, és van egy 
Richard nevű macskája. Minden észrevételt, megjegyzést, 
levelet szívesen fogad. 


Hogyan térjunk át Linuxra lépésről lépésre? (4. rész) 


Irodai programcsomagok nyújtotta lehetőségek Linux alatt. 


számítógép-használat során a leggyakrabban 
AA szövegszerkesztéssel, táblázatkezeléssel és bemu- 

tatókészítéssel foglalkozunk. Mi sem bizonyítja 
ezt jobban, mint az, hogy a legtöbb számítógép-kezelői 
tanfolyam oktatási anyaga is pont erre a területre irányul. 
Elmondhatjuk tehát, hogy időnk nagy részét irodai prog- 
ramcsomagok használatával töltjük, így elvárható, hogy 
rendszerünk kifogástalanul, minden igényt kielégítően 
szolgálja ki a felmerülő igényeket. Ezt a Linux háza táján 
is pontosan tudják: a fejlesztők igyekeznek a kedvünkben 
járni, ennek következtében a kezdeti lemaradást gyorsan 
sikerült behozni. Ma már nagyon hatékony és szabadon 
hozzáférhető programok állnak rendelkezésünkre, ame- 
lyeknek a használata mindössze alig különbözik már jól 
megszokott windowsos társaikétól. 





Ingyenes, naprakész, hatékony 

Ha marketinges lennék, ezzel a három szóval tudnám leg- 
inkább jellemezni a linuxos irodai programkínálatot. Gon- 
dolom, az ingyenesség előnyét nem kell hosszan ecsetelnem, 
hiszen mindenki pillanatok alatt el tudja képzelni. Ennek 
ellenére mégis érzékeltetni szeretném egy kicsit. Most ne 
feltétlenül otthoni felhasználóként gondolkodjunk, hanem 
egy kis- vagy középvállalkozás informatikai vezetőjeként. 
Ilyen környezetben már messze nem mindegy, hogy mire 
adjuk a fejünket. Esetleg vállaljuk, hogy az összes gépre mé- 
regdrága irodai csomagot vásárolunk, s emellett természete- 
sen azt az operációs rendszert is megvesszük, amelyik elen- 
gedhetetlen a programcsomag-futtatáshoz. Vagy úgy gon- 
doljuk, hogy egy fillér kiadás nélkül a Linuxot választjuk a 
terjesztés mellett fellelhető, abszolút versenyképes irodai 
programokkal, s a megtakarított összeget (ami 10-15 gép 
esetében már milliós nagyságrendű) a géppark korszerűsíté- 
sére tesszük félre. Az utóbbi esetben - természetesen, ha a 
munka hatékonysága nem romlik - a főnökünk valószínűleg 
igencsak meg fogja veregetni a vállunkat. Emellett magánem- 
berként sem mindegy, hogy mennyit áldozunk a méregdrága 
vas megvétele után arra, hogy azt még használni is tudjuk. 
Ami a naprakészséget illeti: szinte heti rendszerességgel 
érhetők el az újabbnál újabb frissítések, foltok, valamint 

a termékek életciklusa is sokkal rövidebb, mint például a 
Microsoft által fejlesztett Office programcsomag esetében. 
A hatékonyság tekintetében is sikerült utolérni a verseny- 
társat, de erről részletesebben az egyes programok 
bemutatása során szólok majd. 
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Lássuk a medvét! 

Avagy nézzük meg, miből is gazdálkodhatunk. A csomagok 
területén két nagy képviselővel találkozhatunk: az egyik 

a KDE munkakörnyezethez fejlesztett KOffice csomag, a 
másik pedig a Sun által elkezdett, de azóta már átalakult 
OpenOffice.org nevű irodai együttes. Ezenkívül természe- 
tesen léteznek még önálló elemek is, mint például a 
GNUMAeric, amely a Gnome grafikus felület táblázatkeze- 
lője, vagy a Spreadsheet nevű egyszerű programocska, de 
nem maradhatnak ki a felsorolásból az olyan Word-klónok 
sem, mint például az AbiWord. 

A mindennapos használat során célszerű azonban a teljes 
csomagokat használni (lehetőleg egyfélét), mert ekkor 
megvan az az előnyünk, hogy az egyes összetevők , beszél- 
getni" tudnak egymással, például táblázatokat helyezhe- 
tünk át dokumentumokba, bemutatókba. A két nagy ver- 
senytársat összehasonlítva azt látjuk, hogy míg a KOffice 
beépített, de viszonylag egyszerű megoldást kínál a fel- 
használóknak, addig az OpenOffice.org inkább a vállalati 
környezetben is kiválóan használható nagyméretű, széles 
körben használható, ugyanakkor egy kicsit lassúbb prog- 
ramcsomag. A továbbiakban ezt a két csomagot szeretném 
bemutatni, ám a kísérteties hasonlóság miatt — amely a 
windowsos programokra emlékeztet minket — a haszná- 
latukról nem szólnék részletesen, ezzel ugyanis senkinek 
sem lehet gondja a későbbiek során. 


KOffice 


Csakúgy, mint a már megszokott rendszerek, ez az össze- 
állítás is az alapvető, gyakori elemeket tartalmazza: a KWord 
nevű szövegszerkesztőt, amely szinte az összes jelenleg 
használatos fájlformátummal (beleértve a Word dokumen- 
tumformátumot is) megbirkózik; a KSpread nevű táblázat- 
kezelőt, amely szintén kezeli a versenytársak állományait; 

a KPresenter nevű bemutatókészítőt (presentation); valamint 
a Kivio nevű diagramrajzoló programot. Ezenkívül olyan 
kiegészítők tartoznak ide, mint a KFormula nevű egyenlet- 
szerkesztő, a Karbon vektorgrafikus rajzoló, a KChart diag- 
ramrajzoló vagy a Korganizer névre hallgató határidőnapló. 
Ezek mindegyikéről elmondható, hogy külsejét és haszná- 
latát tekintve a hagyományteremtő Microsoft Office 
programok másolata, ezáltal nyugodtak lehetünk afelől, 
hogy a használat során nem ütközünk nehézségekbe. 
Külön figyelmet érdemel, hogy minden összetevő ismeri 

a neki megfelelő windowsos fájlformátumot is, tehát a 


2004. március 99 


0 Kiskapu Kft. Minden Jog fenntartva 


0 Kiskapu Kft. Minden Jog fenntartva 


hordozhatósággal sem lesznek gondjaink, bár a bonyolult 
függvényeket használó táblázatoknál vagy az összetett 
elemeket tartalmazó dokumentumoknál támadhat némi 
nehézségünk - ezek azonban az esetek többségében egy- 
két kattintással orvosolhatók. 


Telepítés 

A jó öreg SuSE-terjesztésnél maradva álljon itt néhány sor 
telepítési útmutató gyanánt: nincs más dolgunk, mint rend- 
szerünket a YaS1 segítségével a programcsomagot alkotó 
összetevőkkel bővíteni. A YaSI csomagkezelő (Szoftver tele- 
pítése, eltávolítása) moduljával keressünk rá a koffice kife- 
jezésre, és a találati listában válasszuk a koffice nevű csoma- 
got. Ez önmagában csak az összeállítás közös fájljait és a függ- 
vénytárakat tartalmazza. A lista aljában találhatók a valódi 
összetevők: koffice-illustration, koffice-presentation, koffice- 
spreadsheet, koffice-wordprocessing. Ha ezeket kiválasztottuk, 
kattintsunk az Elfogad gombra, majd hagyjuk jóvá a rend- 
szer által mutatott függőségi listát, s kezdődhet a telepítés. 

A telepítés befejeztével a KDE menü Irodai alkalmazások 
menüpontja alatt fellelhető programok listája egy-két elem- 
mel gazdagodott; próbaképpen bátran indítsuk el őket! 


KWord 

Elindítás után egy Word kinézetű felület köszönt bennün- 
ket. Alapértelmezetten egy ablak pattan fel, amelyen fájlt 
nyithatunk meg vagy sablonon alapuló új dokumentumot 
hozhatunk létre. Ha egy kicsit jobban szemügyre vesszük 
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1. kép A KWord szövegszerkesztő 


a Dokumentum megnyitása fület, azonnal megtapasztalhat- 
juk, hogy hányféle formátumot kezel. Az sem gond tehát, 
ha valakitől másfajta szöveget kapunk, nekünk attól még 
nem kell lemondanunk a program használatáról. A prog- 
ram egyébként a legtöbb megszokott feladatot ellátja: képe- 
ket szúr be, diagramokat, egyenleteket kezel, táblázatok 
szerkesztését teszi lehetővé, sablonok alkalmazását, felso- 
rolást, számozást támogat, van benne helyesírás-ellenőrző, 
kezeli a fej- és láblécet, körlevelet készíthetünk vele, s 
mindezt a már jól megszokott formában. Kedvezőtlen 
vonásakért fel lehet róni, hogy ezeket nem olyan kifino- 
multan teszi, mint windowsos társa, ám mint tudjuk, ott 
sem használjuk minden nap a különleges lehetőségeket, 
így azt mondhatjuk, hogy a mindennapos szükségleteket 
általában bőségesen kielégíti. 


Linuxvilág 
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2. kép A KSpread táblázatkezelő 


KSpread 

A KOffice táblázatkezelőjéről nagyjából ugyanazok mond- 
hatók el, mint a KWordről. Szinte mindent tud, de csak a 
maga szerény módján. Hiányzik például az a szolgáltatás, 
hogy függvény beszúrásakor egérrel kijelölt tartomány 
esetében látni lehessen a tartomány határait, viszont ment- 
ségére legyen mondva: kifogástalanul működik. A függ- 
vénytár is meglehetősen gazdag, viszont a függvényelne- 
vezések tekintetében gond lehet, ha más nyelvű, más 
formátumú fájlt nyitunk meg (például Excel-dokumentu- 
mot). A program egyébként csereszabatos (compatible) 

a KWorddel és természetesen a többi összetevővel is: 
szabadon szúrhatunk be KWord-szöveget a KSpreadbe és 
fordítva. Hatalmas előnye, hogy szembetűnően gyorsan 
dolgozik, s higgyük el: kiválóan használható. 


KPresenter 

Ez a program a Microsoft PowerPoint koffice-os megfele- 
lője, segítségével mindenféle bemutató elkészíthető. lalán 
ennél éreztem úgy, hogy az általam eddig elkészített bemu- 
tatók könnyebben megvalósíthatók voltak, mint Power- 
Pointban. A külső itt is egyszerűbb, de minden elérhető, 
amire feltétlenül szükségünk van. Minden diához leírást, 
szöveget fűzhetünk, amely segít nekünk, hogy a későb- 
biekben is megértsük a diákon feltüntetett csekély mennyi- 
ségű adatot. Ez a KPresenterben alapértelmezetten fél 
képernyőnyi területet kap, kiemelve egyúttal a jegyzet 
használatának fontosságát. Ezenfelül természetesen a 
sablonoktól a diák közötti átmenet szerkesztéséig mindent 
beállíthatunk, s a KPresenter esetében is igaz, hogy sebes- 
ségében Linux alatt a leggyorsabbak közé tartozik. 


KIVIO 

Ez egy folyamatábra- és diagramrajzoló program, amely 
egy kissé szokatlan az eddigiekhez képest, hiszen ilyet nem 
mindegyik irodai programcsomag tartalmaz. A használatát 
valahogy úgy kell elképzelni, hogy elkészítünk benne egy 
látványos ábrát, például országok zászlajával, Európa-tér- 
képpel és minden egyéb nyalánksággal, majd a művet 
egyrészt kinyomtathatjuk, másrészt egy KPresenter-diára 
objektumként beszúrhatjuk, változatosabbá téve ezáltal a 
bemutatót. lovábbá azt az aprócska tényt sem szabad elfe- 
lednünk, hogy nem kell hosszú időn át grafikai programok- 
kal pepecselni, hogy a kívánt látványt elérhessük. A folya- 
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3. kép A Kivio folyamatábra-szerkesztő 


matábrák tekintetében azt kell megemlítenünk, hogy kezeli 
a szabványos jelöléseket: a folyamatábra-alakzatokat, az 
UML-elemeket, így akár egy programfejlesztő is hasznát 
veheti, nem beszélve egy házi feladatát leadni készülő 
diákról. Meg kell hagyni, hogy Windows alatt az ilyesmihez 
külön program szükséges. A program működése egyébként 
vektorgrafikus, amellyel nemcsak memóriát takarítunk 
meg, de a végeredményt is igényesen alakíthatjuk ki. 

Ami a fájlformátumot illeti, lehetőségünk nyílik az állomá- 
nyokat XML formátumban tárolni, amellyel egy újabb 
lépést tettünk meg a hordozhatóság rögös útján, így ugyan- 
is olyan szabványos kimenetet határoztunk meg, amelyre 
más szerkesztőprogramok is támaszkodhatnak. Ezenkívül 
természetesen saját Kivio fájlformátum is létezik, amely az 
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előző XML leírónyelven alapul. 


Karbon14 

Ez egy vektorgrafikus rajzolóprogram, amely a jól ismert 
CorelDraw linuxos megfelelője, s fokozottan igaz rá, hogy 
nem tud minden szolgáltatást, amit az eredetitől megszok- 
tunk, de kétségkívül jól használható. Ha a Kivióval ötvözzük, 
gyakorlatilag áthidaljuk a szolgáltatások szegényessége miatt 
keletkező árkot. A használatáról annyit érdemes tudni, hogy 
itt is a már bevált normákhoz próbáltak igazodni, semmilyen 
vad kezelésbeli újítást nem találunk. A kész művet azután a 
Windows metafájlformátumtól kezdve az Adobe Illustrator 
által kezelt formátumig bárhogyan menthetjük (beleértve 
természetesen a már emlegetett XML formátumot is). 
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4. kép A Karbon14 vektorgrafikus rajzoló 
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KFormula 

Ez a KOffice csomag grafikus egyenletszerkesztője. A prog- 
ramot az esetek többségében nem szükséges elindítani, az 
egyes összetevők használata során a megfelelő műveletre 
kattintva (egyenlet, képlet beszúrása) objektumként elő- 
ugrik; de lehetőségünk van arra is, hogy külön elindítsuk, 
megszerkesszük vele a képletet, majd a másolás-beillesztés 
módszerrel átvigyük a céldokumentumba. Ezenkívül a 
formulát későbbi használat céljából menteni tudjuk -— ha 
például beszámolót és bemutatót készítünk egyszerre, 
akkor az előre elkészített képleteket beszúrhatjuk a külön- 
böző típusú dokumentumokba. A KFormula is támogatja 
az XML alapú fájlokat, amelyek mellett ugyanazok az érvek 
szólnak, mint a Kivio esetében. 


KChart 

A KOffice csomag grafikonszerkesztője. Túlnyomórészt a 
KSpread programból indul el, de ugyanúgy lehetőségünk 
van különálló programként futtatni s az eredményt men- 
teni — természetesen itt is választhatjuk az XML kimeneti 
formátumot. A program használata során egyébként szá- 
mos grafikontípusból választhatunk és ezek legtöbbjének 
további altípusai is vannak. Minden aprócska megjelenő 
szöveget külön-külön beállíthatunk, színeket kombinálha- 
tunk -— egyszóval gazdag a beállítási lehetőségek palettája. 
Az értékek megadása kézzel történik, oszlop-sor (tábláza- 
tos) formában. Ez azért is hasznos, mert a KSpread grafi- 
konvarázslóját használva sajnos nem sikerült eredményre 
jutnom, az ugyanis következetesen , szabálytalan műve- 
letet" hajtott végre. 


KOffice — összegzés 

Mint láthattuk, a programok nemcsak mintául szolgáló 
elődeikhez, de egymáshoz is igyekeznek igazodni, mind 
kinézetükben, mind működésükben. Ezáltal könnyebben 
sajátíthatjuk el a használatukat, mivel mindet ugyanúgy 
kell kezelni, mindegyiket egyformán kell megnyitni, az 
indítás után ugyanazt a sablonkezelő ablakot kapjuk. A mű- 
ködésbeli hasonlóság ,mellékhatásaként" pedig kiaknáz- 
hatjuk azt a létfontosságú ismeretet, hogy lehetséges az 
egyes összetevők közti adatcsere. Egymás állományait 
ugyanis objektumokként kezelik, ezáltal egy nagy-nagy 
beágyazgatott adathalmazt kezelhetünk, a legváltozatosabb 
eredményeket érve el. Nagy előnye, hogy az egyes 
segédprogramok, mint például a diagramszerkesztő vagy 
az egyenletszerkesztő, akár külön-külön is futtathatók. 

Van azonban néhány korlátja is a csomagnak: az egyik, 
hogy az előugró menük hiánya megnehezíti a kezelést, 

a másik a szolgáltatások terén észrevehető szegényesebb 
ellátottság. Ez természetesen nem azt jelenti, hogy többre 
volna szükség; a legtöbb esetben elég, amit a programban 
találunk, ám ha valami egyedire, különlegesre vágyunk, azt 
a programcsomag segítségével nagy valószínűséggel nem 
tudjuk álmainknak megfelelően megvalósítani. lovábbi kö- 
vetkezményként azonban viszont azt tapasztalhatjuk, hogy 
a program meglehetősen gyorsan fut, s egyszerűségéből 
adódóan a használata is gyorsabb, mert minden kéznél van, 
s az egyszerű menüpontok, gombok között gyorsabban is 
tudunk választani, ami a hosszű, esetleg egyhangúan ismét- 
lődő munka során jelentős időmegtakarítást eredményezhet. 
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Ha nem elég a KOffice: OpenOffice.org 

Még mielőtt az időközben kialakult felhasználótábor a kez- 
detleges megoldásokat hallva elkeseredne (amelyek azért 
nem olyan kezdetlegesek, inkább úgy fogalmaznék, hogy 
egy-két változattal le vannak maradva a piacvezető irodai 
programcsomaghoz képest), gyorsan közhírré szeretném 
tenni, hogy létezik egy sokoldalúbb, s egyúttal bonyolul- 
tabb választási lehetőség is, ami pedig nem más, mint az 
OpenOffice.org Ez a program a Sun által támogatott 
StarOffice-ból nőtte ki magát, miután az nyílt forráskódú 
lett. (Eredetileg teljes irodai munkakörnyezetnek indult 
Start menü-vel és más egyéb kellékekkel.) 

Ez a csomag egyetlen munkakörnyezetnek sem része, tel- 
jesen különállóan működik (az X-felületet használva), s a 
létező változatok segítségével több felületen is használható. 
Saját grafikus telepítőprogrammal rendelkezik, amelynek 
köszönhetően mindenféle szakértelem nélkül telepíthető. 


A telepítés 

Ha SuSE Linux 9.0-t (vagy 8.2-est) használunk, akkor 
semmi dolgunk, az OpenOffice ugyanis része az alapértel- 
mezett összeállításnak, így csak használatba kell vennünk. 
A KDE menü/Irodai alkalmazások és Grafikus programok 
menüpontok alatt találjuk az egyes összetevőket; ám még 

a használatuk előtt néhány szót szólnék a telepítést illetően 
azoknak, akik nem SuSE-felhasználók, vagy épp egy 
régebbi OpenOffice-változat pihen a gépükön, s frissíteni 
szeretnék. Ehhez nem kell mást tenniük, mint hogy elláto- 
gatnak a 3 http:/download.openoffice.org/index.html 
címre, és ott kiválasztják a nekik megfelelő OpenOffice.org- 
változatot, majd azon belül a megfelelő nyelvet, operációs 
rendszert, s a programot egy tömörített (tar.gz) állomány 
formájában letöltik. Ezt azután parancssorból a tar -czvf 
cfájlnév: paranccsal egy üres könyvtárba csomagolják ki, 
majd a ./instal1] parancs kiadásával indítsák el a saját 
telepítőjét. Ha már volt a rendszerükön egy régebbi Open- 
Office-változat, a telepítő ezt önműködően felismeri, s a 
parancssor képernyőjén visszajelezve régi programunkat 
az új változatra fÍrissíti. Amennyiben azonban még nem ren- 
delkezünk vele, úgy egy grafikus telepítőprogram indul el, 
ami érthetően végigvezet bennünket a telepítés folyamatán. 


A program 

A legújabb változatot elindítva csak egy , ablakkeretet" 
kapunk, amelyből megnyithatjuk a kiszemelt dokumen- 
tumot vagy újat hozhatunk létre. Kezdetnek válasszuk a 
Fájl menü/új szöveges dokumentum menüpontját, s próbál- 
junk meg a megjelenő ablakban található program és 
windowsos megfelelője között különbségeket keresni. 

A fenti feladat akár fejtörő is lehetne, hiszen az, amit lá- 
tunk, a megszólalásig hasonlít a Word kinézetére. Műkö- 
dése is csak abban különbözik, hogy sokkal összefogottabb, 
itt ugyanis mindenféle dokumentumtípushoz (vektoros 
rajz, táblázat, szöveg) egy programon belül férünk hozzá, 

s a Fájl menü/új menüpontjának segítségével bármilyen 
típusú dokumentum szerkesztése közben új táblázatot, 
szöveges dokumentumot vagy épp HIML-dokumentumot 
nyithatunk meg. Az egyszerűség kedvéért azonban a rend- 
szer menüjébe (KDE menü) szétválasztva kerülnek bele, s 
ha az adott menüpontra kattintva indítjuk őket, az alap- 
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6. kép A Calc táblázatkezelő 


program minden esetben elindul, de a parancs azonnal meg 
is nyit számunkra a kért dokumentumtípusból egy újat. 
Ha már itt tartunk, nézzük meg, hogy milyen elemekből 
épül fel a programcsomag! lermészetesen ez is a klasszikus 
összetevőket tartalmazza: szövegszerkesztő (Writer), táblá- 
zatkezelő (Calc), bemutatókészítő (Impress) és az annyira 
szokványosnak nem nevezhető rajzolóprogram, a Draw. 
A rendszer beépített, jól működő helyesírás-ellenőrzőt is 
tartalmaz, amely önműködő üzemmódban ugyanúgy 
viselkedik, mint azt már megszokhattuk: a hibásnak vélt 
szavakat hullámos vonallal aláhúzza. (Itt azonban az 
önműködő ellenőrzés nem alapértelmezett, az Eszközök/ 
Helyesírás-ellenőrzés/Automatikus helyesírás-ellenőrzés 
menüpontban nekünk kell bekapcsolni, függetlenül attól, 
hogy épp milyen típusú dokumentumot szerkesztünk.) 
Minden elemről elmondható az, hogy gyakorlatilag az 
összes megszokott szolgáltatást megvalósítja: gazdagon 
paraméterezhető, sokszínűen beállítható lehetőségeket 
kapunk; ám azt az árat fizetjük érte, hogy a program 
(legalábbis SuSE alatt) elég lassúcska. Nyugodjunk meg, 
azért még mindig kényelmesen használható. 


OpenOffice.org Writer 

Az előbbi művelet során is ezt láthattuk működni - tökéle- 
tesre sikerült Word-másolattal van dolgunk. Bárhogyan 

is nézem, semmi újat nem tudnék elsőre elmondani a prog- 
ramról, s hasonlóképpen így vagyok a hátrányok ismerteté- 
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7. kép A Draw vektorgrafikus rajzoló 


sével is. Most már számtalan órája ülök előtte, hiszen 

e program segítségével készül a jelenlegi cikk (és minden 
egyéb általam , gyártott" mű is), de nem igazán tudok kü- 
lönbséget tenni a Word és a Writer között. Egy talán mégis 
akad, amelynek a közelmúltban jó hasznát vettem: a Writer 
nemcsak a saját formátumait kezeli, hanem a különböző 
irodai programcsomagok által használatos állományok 
szinte mindegyikét. Hasonló dolgokról beszéltem fentebb 

a KOffice esetében is, de ha lehet, itt még bővebb a használ- 
ható formátumok palettája, s a csomag többi összetevőjéről 
is pontosan ugyanez mondható el. Akad olyan ismerősöm 
is, aki az OpenOffice-nak csak ezt az előnyös tulajdonságát 
használja ki, és átalakítóként (konverter) veszi igénybe. 


OpenOffice.org Calc 

Ez a program a csomag táblázatkezelője. Ha elindítjuk, azt 
tapasztaljuk, hogy ez is pontosan úgy néz ki, mint az Excel, 
s elmondhatom, hogy nagyjából ugyanazt is tudja! Vannak 
természetesen eltérések és apróbb hiányosságok, de ezt az 
általános használat során a szerényebb képességű KSpread 
esetében sem vesszük észre. 


OpenOffice.org Impress 
A diavetítő és bemutatókészítő program ismét windowsos 


megfelelőjéhez hasonlít, s a használata is körülbelül annyira 
bonyolult. Legnagyobb előnye szerintem, hogy jól kezeli a 





vektorgrafikus objektumokat, így közvetlenül szerkeszthe- 
tünk olyan folyamatábrákat, modelleket, amelyeket azután 
kedvünk szerint alakítgathatunk; nem áll fenn az a veszély, 
hogy eltorzul az ábra vagy a nyilak épp nem a megfelelő 
irányba mutatnak. Minden elfogultság nélkül mondhatom, 
hogy a programcsomag ezen a területen messze lekörözte 
minden versenytársát, mert ilyen hatékonyan egyikkel sem 


tk 


sikerült előállítanom a kívánt eredményt. 


OpenOffice.org Draw 

Ez az a program, amely a fenti dicséretet megérdemli. 
Olyan vektorgrafikus rajzoló, folyamatábra-szerkesztő, 
grafikonrajzoló program, amely ötvözi a Karbon és a Kivio 
előnyös tulajdonságait, s a gyakorlatban helyettesítheti a 
CorelDraw méregdrága programját is, hiszen okos grafikus 
objektumainak a segítségével szélsebesen dolgozhatunk. 


Összegzés 

A program ezeken túlmenően beépített képletszerkesztőt 
tartalmaz, amit szöveges leírónyelvvel is utasíthatunk (nem 
kell a megfelelő ábrákra kattintani, s ez a programozó 
hajlamú felhasználóknak általában nagyon tetszik), grafi- 
konok készítését teszi lehetővé a táblázatkezelés során, egy- 
szóval kerek, egész irodai munkakörnyezetet kínál nemcsak 
az otthoni, de az irodai felhasználók számára is, s ne feled- 
jük, hogy mindezt teljesen ingyen. Ha azonban valaki a 
bemutatott csomagokat nem szívleli, még mindig szabadon 
választhat használható szövegszerkesztőket, táblázatke- 
zelőket, bármit, amire szüksége van. 

Ismét elmondhatjuk, hogy a Linux ezen a területen is kiállja 
a próbát, sőt néhány pontban oda is csap az ellenfeleknek, 

s ezzel gyakorlatilag elérkeztünk oda, hogy új operációs 
rendszerünket épp olyan jól tudjuk használni, mint annak 
előtte a Windowst vagy bármelyik felhasználóbarátnak 
mondott operációs rendszert. A sorozat következő részében 
az internetes csevegő és üzenő szolgáltatások világában 
teszünk , áttekintő" kirándulást. 


Komáromi Zoltán 
(komi(okiskapu.hu) 

23 éves, a BME hallgatója, mellette 
PHP-programozóként dolgozik. 
Kedvenc területe a multimédia. 





www.linuxvilag.hu 


2004. március 63 


0 Kiskapu Kft. Minden Jog fenntartva 


IDON 


Linuxos kiszolgálót mindenkinek! (4. rész) 


A SuSE Linux mint kiszolgáló - kisvállalati és otthoni környezetben. 
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első tényleges szolgáltatásait az ügyfelek számára, 
nevezetesen fájlkiszolgálót és DHCP-kiszolgálót 
létesítettünk, amelyekkel a helyi hálózat támasztotta 
igények egy részét ki tudjuk elégíteni. Most azt a szolgál- 
tatást nézzük meg, ami a számítógépes hálózatok egyik 
úttörő szolgáltatása és az internetfelhasználók egyik leg- 
kedveltebb, leghatékonyabb információközlő eszköze: 
az elektronikus levelezést. 
Az elektronikus levelezés működéséhez több különböző 
feladatot ellátó programnak, az úgynevezett ügynököknek 
(agent) az együttműködése szükséges. Az egyes ügynökök 
a levelezés folyamán különböző feladatokat látnak el: az 
MUA (Mail User Agent - Felhasználói levelezőügynök) 
feladata a levélnek a felhasználói oldalon történő össze- 
állítása, szerkesztése. Ezek gyakorlatilag a felhasználó által 
használt levelezőprogramok, ilyen a Mozilla Mail, a Pine 
vagy az Evolution. 
Az MDA (Mail Delivery Agent - Levélkézbesítő ügynök) 
feladata az adott kiszolgálón az őt címzettként megjelölő 
üzeneteknek a rajta lévő megfelelő postafiókba való 
eljuttatása. 
Az LDA (Local Delivery Agent — Helyi kézbesítőügynök) 
feladata a helyi címzettnek küldött leveleknek a megfelelő 
postaládába rendezése. Az LDA a rendszerek többségében 
megegyezik az MDA-val. Linuxos rendszer alatt ilyen 
ügynök például a procmai I. 
Utolsóként beszéljünk az MIA-ról (Mail Iransfer Agent 
- Levéltovábbító ügynök), amelynek a leveleknek a 
megfelelő kiszolgálóhoz való eljuttatása a feladata. Linuxos 
rendszeren ilyen például a Postfix, a Sendmail vagy az 
Exim. Jelen cikkünk gerincét a Postfix beállításának az 
ismertetése alkotja, SuSE 9.0-s rendszer alatt. 


A Postfix 
A Postfix levélkiszolgáló telepítéséhez indítsuk el a YaS1-ot, 


és a már jól megszokott módon pakoljuk fel a Postfix 
csomagot. Ha a csomagot telepítettük, a /etc/postfix könyv- 
tárban lesznek a kiszolgáló beállításait tartalmazó állomá- 


8 orozatunk előző részében beállítottuk a kiszolgáló 





nyok, a /usr/sbin könyvtárban találjuk meg a kiszolgáló tárolni, így a várakozási sorban lévő és a visszautasított 
futtatható állományát, valamint a /etc/init.d könyvtárba levelek is itt lesznek megtalálhatóak. Ez azért fontos, mert 
kerülnek a kiszolgáló indításához és leállításához haszná- ha esetleg rossz beállítással futtatjuk a kiszolgálót, óriási 
latos parancsállományok. mennyiségű felesleges levéllel töltheti fel a rendszert — e 


Továbbá a telepítő létrehozza a /var/spool/postfix könyvtárat, . könyvtárak kiürítésével tudjuk a felesleges elemeket törölni, 
amelyben a kiszolgáló a feldolgozás alatt álló leveleketfogja — s ezzel megelőzhetjük a rendszer esetleges összeomlását. 
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A YaST a harátunk 


Mint azt már megszokhattuk, a SuSE ismét kínál egy 
eszközt, amellyel kiszolgálónk alapbeállításait el tudjuk 
végezni. A YaS1I Hálózati szolgáltatások menüpontja alatt 
található Levéltovábbító szerver modult indítva lehetővé 
teszi számunkra az elsődleges levélkiszolgáló szabványos 
felületen történő beállítását. 

A megjelenő Kapcsolat típus ablakban ki kell választanunk 
a hálózati kapcsolatunkat. Ha interneten keresztül is 
szeretnénk levelezni, tehát nem csak egyfajta vállalati 
levelezést szeretnénk megvalósítani, internetkapcsolatunk 
típusától függően válasszuk az Állandó vagy a Betárcsázós 
kapcsolat-ot. Amennyiben , betárcsázással" kapcsolódunk 
az internetre, a levelező a várakozási sorba érkező 
leveleket nem továbbítja önműködően, elindítá- 
sukat a sendmail -g parancs révén kézzel 
tehetjük meg. Ilyen esetben természetesen 
írhatunk egy olyan parancsállományt, 
amely az internetes kapcsolat létrejötte- 

kor lefuttatja a várakozási sor ürítésére 
szolgáló parancsot. 

Amennyiben víruskereső szolgáltatást is 
szeretnénk kapcsolni a levélkiszolgálóhoz, 
azt a Víruskeresés engedélyezése bekapcso- 
lásával tehetjük lehetővé. Ha az Amavis 
víruskereső nincs telepítve, a YaS1l ezt is 
elvégzi helyettünk. 

A következő lépésben megadhatjuk a levelek 
továbbítására használni kívánt SMIP-kiszolgá- 
lót. A mező értékének adjuk a localhost érté- 
ket, amennyiben a jelenleg telepített kiszolgálót 
szeretnénk használni. Ha azonban egy másik kiszol- 
gálóval szeretnénk a leveleket továbbítani, a teljes 
internetcímét adjuk meg. 

Az Álcázás gombra kattintva lehetőségünk nyílik gépünk 

és felhasználóink alapértelmezett nevének és címének a 
felülírására. Ez akkor lehet hasznos, ha a rendszert internetes 
és belső hálózati (intranetes) környezetben egyaránt használ- 
juk, valamint több címtartományt is kiszolgálunk, ezért 
különböző felhasználóinkhoz különböző címek tartoznak. 

Az első sorban a Doménnév a From (küldő) fejlécmező szá- 
mára mezőben megadhatjuk a kiszolgálóhoz tartozó elsőd- 
leges címet, így amennyiben például a gépünk a 
kiszolgalo.tartomany.hu címmel azonosítható és mi ebbe 

a mezőbe a tartomany.hu értéket írjuk, a 
felhasznalocakiszolgalo.tartomany.hu helyett a kimenő levelek 
feladója minden esetben a felhasznalo(otartomany.hu lesz. 

A Doménnevek helyi kézbesítéshez mezőben megadhatjuk, 
hogy a helyi levelek kézbesítésekor a felhasználó neve után 
milyen cím szerepeljen. lovábbá lehetőségünk van annak 

a beállítására is, hogy csak a helyi nevet akarjuk-e álcázni 
vagy egyéb címeket is felül akarunk-e írni. Ezenkívül azt 

is megtehetjük, hogy minden egyes felhasználónkhoz egye- 
sével rendelünk hozzá elektronikus levélcímeket. Ehhez 

a Hozzáadás gombot szükséges használnunk, és a felhasz- 
nálót ki kell választanunk a listából, valamint meg kell adni 
a hozzá tartozó elektronikus levélcímet. Ezzel az Álcázás 
menüpont beállítási lehetőségeinek a végére értünk — az 
OK-ra kattintva visszatérünk a Kimenő levelek ablakba. 

Az Azonosítás gombra kattintva lehetőségünk van elérési 
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jellemzők megadására a szolgáltatónk által rendelkezé- 
sünkre bocsátott SMIP-kiszolgálóhoz, ha a szolgáltató ezt 
a levelek elküldéséhez kérné. Amennyiben a saját gépün- 
kön (localhost) lévő kiszolgálót használjuk, és előzőleg 
nem állítottunk be elérési korlátokat, ezeket a mezőket 
nyugodtan kihagyhatjuk. 
A következő megjelenő ablak a Bejövő levelek ablaka; itt 
lehetőségünk nyílik beállítani, hogy a bejövő levelek 
melyik címzetthez kerüljenek, továbbá azt is, hogy a helyi 
kiszolgálónk egy másik levélkiszolgálóról töltse le a ne- 
künk szóló leveleket, éppen úgy, mint azt a levelezőprog- 
ramok is teszik. Az utóbbinak 
akkor van értelme, 
ha kapcsolt vonali 
internetszol- 


gáltatással 
rendelkezünk, 
ezért nincs rá 
lehetőség, hogy 
közvetlenül a kiszol- 
gálónak címezzék azokat. 

Nézzük először a levelek kézbesíté- 

sének a beállításait! A root leveleinek továbbítása az alábbi 
felhasználónak változó értékeként adjuk meg azt a felhasz- 
nálót, akinek a rendszergazdához érkező leveleket továbbí- 
tani szeretnénk. Ez azért szükséges, mert a root-ot álta- 
lában nem használjuk levelezési célokra, a rendszer felü- 
gyeletét végző embernek pedig valószínűleg egy külön 
felhasználót hoztunk létre, így neki továbbíthatjuk az olyan 
leveleket, amiket a rendszergazdának kell megkapnia, 
például a naplóállományokat, a riasztásokat. 
Kézbesítési mód-ként válasszuk a procmailen keresztül 
lehetőséget, ami azért lesz hasznos, mert a procmai ! LDA- 
hoz tartozik egy központi és egy felhasználótól függő 
beállításállomány, amiben a levelek szűrését, csoportosítását 
központilag vagy külön-külön is szabályozni tudjuk. 
Bővebb tájékoztatással a procmai 1] súgóállománya szolgál. 
Az Álnevek gombra kattintva szerkeszthetjük a /etc/aliases 
állományt, amely a helyi felhasználó-kézbesítési hely páro- 
kat tartalmazza. Itt lehet beállítani, hogy az adott felhasz- 
nálónak érkező levelet a levelező hová továbbítsa. Ez lehet 
egy másik helyi felhasználó, de egy másik gépen lévő 
felhasználó is, emiatt itt akár egy elektronikus levélcímet 
is megadhatunk. 
A Virtuális domének gombra kattintva a /etc/postfix/virtual 
állomány tartalmát szerkeszthetjük. Ennek hasonló a 
szerepe, mint a /etc/aliases állománynak, de itt a bal olda- 


2004. március 65 


0 Kiskapu Kft. Minden Jog fenntartva 


0 Kiskapu Kft. Minden Jog fenntartva 


1l.kép A bejövő levelek beállítása a YaS1-ban 


lon megadhatunk felhasználót, tartományt vagy akár 
elektronikus levélcímet is. Például beállítható, hogy a 
tartomany.hu tartomány bármelyik felhasználójához érkező 
levelet egyvalaki kapja meg. Lássunk egy-két példát! 

Ha egy olyan bejegyzést készítek, aminek a bal oldalán az 
inforwvtartomany.hu áll, míg a jobb oldalon a titkárnő, akkor 
a fenti elektronikus levélcímre érkező leveleket a titkárnő 
felhasználó fogja megkapni. Amennyiben olyan szabályt 
készítek, hogy a Otartomány2.hu: főnök, akkor a 
tartomány2.hu tartományba érkező összes levelet a főnök 
felhasználó kapja meg. lovábbi útmutatást a man virtual 
paranccsal kaphatunk. Mind az aliases, mind pedig a 
virtual állományokat a fent leírt helyeken kézzel is szer- 
keszthetjük, de a szerkesztés után az adatbázist is frissíteni 
kell. Első esetben ezt a new al iases, az utóbbiban a postmap 
/etc/postfix/virtual paranccsal tehetjük meg. 

Utolsó beállításként nézzünk egy hasznos eszközt azok 
számára, akiknek különböző szolgáltatóknál vannak pos- 
taládái, ideiglenes kapcsolattal rendelkeznek, és így nincs 
lehetőségük közvetlen levélfogadásra a nap minden 
percében. A Linux ennek feloldására is kínál egy eszközt, 

a Fetchmailt. Ezzel a programmal a megfelelő beállításál- 
lományban megadott értékekkel csatlakozik a gépünk a 
távoli kiszolgálóhoz és onnan a megfelelő levelezőprotokoll 
használatával letölti leveleinket a saját kiszolgálónkra, így 
olyan módon tudjuk kezelni őket, mintha közvetlenül 

a kiszolgálónkra érkeztek volna. 

Egy ilyen beállítást ki is tudunk tölteni a Bejövő levelek 
oldalon, de ha a Részletek gombra kattintunk, a felbukkanó 
új ablakban egész listát vehetünk fel a különböző felhasz- 
nálókhoz. A Hozzáadás gomb megnyomására felbukkanó 
ablakban meg kell adnunk a kiszolgáló nevét: ez a távoli 
postaládánkat tároló kiszolgáló címe lesz; a használni 
kívánt protokollt, ami általában vagy a POP3 vagy az IMAP 
továbbá meg kell adnunk a távoli felhasználó nevét jelsza- 
vát, amivel hozzáférésünk lesz a rendszerhez; és végül be 
kell írnunk a felhasználót, akinek a helyi gépen a leveleket 
le akarjuk tölteni. 

Ha végeztünk a lista elkészítésével, az itt felvett jellemzők a 
l/etc/fetchmail.rc állományban mentésre kerülnek, amelyben 
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3. kép Virtuális címek és kézbesítési helyük 


a későbbiek során a listát kézzel is szerkeszteni tudjuk. 

Az állomány szerkesztésével lehetőségünk van SSL-kap- 
csolattal is ellátni a letöltést, így a jelszavak és az adatok 
titkosítva haladnak a távoli kiszolgáló és a miénk között 

-— amennyiben ezt a távoli kiszolgáló számunkra lehetővé 
teszi. Ehhez a létrehozott bejegyzés végére be kell szúrni 
az options ss! tagot. 

Ha ezzel is végeztünk, zárjuk be a varázslót, amely elkészíti 
nekünk a levélkiszolgáló alapbeállításait. 


Nézzük meg a beállításokat közelebbről is! 

Bár a varázsló ügyes megoldás a SuSE részéről, korántsem 
lehet minden apró lehetőséget kiaknázni vele, ezért lehet, 
hogy kézzel is bele kell nyúlnunk a beállításokba. 

Először nézzük a /etc/postfix/main.cf állományt. Megvizs- 
gálunk pár beállítást, amit a kiszolgáló biztonsága érde- 
kében mindenképpen el kell végeznünk. Az első ilyen a 
mynetworks - ennek a változónak az értéke azt mutatja 
meg, hogy az SMIP-kiszolgáló mely hálózatoknak nyújt 
levélküldési szolgáltatást. Ahhoz, hogy elkerülhessük a 


a Lf 


reklámozók rajtunk keresztüli történő levélszemétküldését 
(spam), ezt a változót olyan módon kell beállítanunk, 

hogy csak a saját gépről (localhost), esetleg a belső hálózat 
IP-tartományából fogadjon el levelet küldésre. Például a 
mynetwhorks-127.0.0.0/8 10.0.0.0/24 beállítás csak a 
saját gépről, valamint a 10.0.0.1 és 10.0.0.254 közötti gépek- 
ről fogad el levélküldési parancsot. Egyes ügyfeleket adha- 
tunk meg IP-címmel, vagy hálózatokat címmel és hálózati 
maszkkal, egyszerű felsorolásként, szóközzel elválasztva. 
A myorigin változó tárolja a kiszolgáló elsődleges tarto- 
mánynevét. A mydestination változóban tartományneve- 
ket sorolhatunk fel vesszővel elválasztva, ezeket fogja a 
kiszolgáló a beérkező leveleknél címzettként elfogadni. 
Amennyiben azt szeretnénk, hogy a levél beérkezése után 
a Postfix a feldolgozást adja át a procmai 1-nek, valamint 

a felhasználók szűrési szabályokat tudjanak írni, a 

mailbox command - procmai 1] -a "$EXTENSION" sornak 
mindenképpen szerepelnie kell a beállítások között. 
Amennyiben a rendszer terhelésének ellenőrzéséhez korlá- 
tozni szeretnénk a postaládák méretét, illetve meg kívánjuk 
adni az elküldhető levél legnagyobb méretét, ezt a 
mailbox size limit és amessage size limit változók 
beállításával tehetjük meg. Mindkét változó egy számot 
vár értékként, ez a szám pedig a méret leírása bájtokban. 
Például az 1 MB-os postaládaméret beállításához a 
mailbox size limit-1024000 értéket szokták megadni. 

A fetc/postfix/virtual állomány tárolja a virtuális tarto- 
mányokhoz tartozó elektronikus levélcímeket és felhaszná- 
lókat, ha ilyet a varázslón keresztül készített beállításban 
megadtunk. Amennyiben eddig nem tettük volna meg, a 
fent leírt szabályokat itt is meg tudjuk adni. Bal oldalon azt 
a címzettet vagy címtartományt szükséges beírni, ahová a 
levél érkezik, majd egy szóköz után azt a helyi felhasználót 
vagy elektronikus levélcímet kell megadnunk, ahová a 
szabálynak megfelelő levelek továbbítódnak. Így tudunk 
olyan elektronikus levélcímeket is létrehozni, amelyekhez 
nem tartozik valóságos felhasználó a rendszerben, hanem 
csak egy távoli postafiókba továbbítjuk a levelet. 

Ne felejtsük el azonban, hogy az állomány módosítása után 
a postmap /etc/postfix/virtual parancsot le kell futtat- 
nunk - ha a virtual állomány a /etc/postfix könyvtárban 
helyezkedik el — ahhoz, hogy a változásokat a rendszer 
érvényre juttassa. A mindenkori adatbázis a 
letc/postfix/virtual.db állományban található. 

A /etc/postfix/access állományban állíthatjuk be a szűrési 
feltételeket az elektronikus levelek feladójára, a teljes 
elektronikus levélcímre vagy az elektronikus levél feladó- 
jának tartományára. Ezzel egy egyszerű levélszemétszűrést 
állíthatunk be, ami mostanában már sajnos nem túl haté- 
kony, mert a levélszemétküldők vagy állandóan változó 
címet használnak, vagy úgy választanak címet, hogy a 
feladót a saját tatományunkból érkezőként állítják be. 

A szűrési feltétel egy párosból áll, amely egy mintából 

és egy cselekvésből tevődik össze. 

Minta lehet egy elektronikus levélcím, például a 
felhasznalotokiszolgalo.tartomany.hu -— ekkor a teljes címet 
figyeljük, vagy a cím töredéke (felhasznalo(w), amikor is a 
felhasznalo nevű felhasználóktól érkező levelek kerülnek 
szűrésre, függetlenül attól, hogy a levél milyen tarto- 
mányból érkezett. Végül, de nem utolsósorban a szűrési 


www.linuxvilag.hu 


feltétel lehet egy tartomány, tehát például a 
kiszolgalo.tartomany.hu vagy a tartomany.hu. Az utóbbi 
esetben természetesen az első példa is szűrt lesz, de emellett 
az összes olyan cím is, ami tartomany.hu-ra végződik. 
Cselekvés lehet a levél eldobása (DISCARD), a levél vissza- 
utasítása (REJECT) vagy a levél elfogadása is (OK). Ezeken 
kívül beállítható még, hogy a beérkező levelet tartalomszű- 
résnek is alávessük, ehhez a FILTER kulcsszót kell megadni. 
Erről és többi beállításról bővebb leírást a man access 
parancs kiadásával kaphatunk. 

A virtual tábla frissítéséhez hasonlóan az access táblát is 
frissíteni kell a postmap paranccsal, pontosabban a postmap 
/etc/postfix/access paranccsal. Ahhoz, hogy ezt a 
szűrést használni tudjuk, a /etc/postfix/main.cf beállításai 
között szerepelnie kell a 

smtpd. sender. restrictions-hash: /etc/postfix/access 
beállításnak. 

Ezzel a legfontosabb beállításokat talán el is végeztük 
levelezőrendszerünkön, ami mostanra már működőképes. 
Ne felejtsük el a tűzfalunkon a megfelelő kapukat kinyitni, 
ha szükségesek, valamint figyeljünk oda arra is, hogy a 
YaS1-on belül a Futási szint szerkesztő-ben szintén be kell 
állítani, hogy a megfelelő futási szinteken a Postfix önmű- 
ködően elinduljon. lovábbá ne feledjük, hogyha a beállí- 
tásokat elvégeztük, a /etc/init.d/postfix restart 
paranccsal indítsuk újra a levélkiszolgálót, hogy az új beál- 
lítások érvénybe lépjenek. 

Ha végeztünk a kiszolgáló beállításával és elindítottuk, 
akkor a biztonság kedvéért kövessük figyelemmel a 
/var/log/mail, mail.err, mail.warn, mail.info naplóállományo- 
kat, hogy a kiszolgálón felmerülő esetleges hibákat mielőbb 
orvosolni tudjuk. Nincs ugyanis kellemetlenebb dolog, mint 
egy rosszul beállított kiszolgáló miatt elkallódó levél. 
Írásom végére érve elmondhatjuk, hogy működő SMTP- 
kiszolgálót hoztunk létre. Sorozatom következő részében 
ezt kiegészítjük azzal, hogy a legnépszerűbb ügyfél-hoz- 
záférési protokollokat telepítjük a rendszerre, foglalkozunk 
a POP3 és IMAP protokollokkal, illetve azok titkosított, 
úgynevezett SSL-változatával. 


lllés Viktor (viktorDei.hu) 

23 éves, a BME műszaki informatikus szakának 
hallgatója, mellette weblapokkal, linuxos 

és windowsos rendszerekkel foglalkozik. 
Szabadidejét legszívesebben a szabadban tölti, 
teniszezik és kerékpározik. 
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Néhány érv az Xdialog mellett és ellen 


Grafikus felhasználói felületek könnyedén és gyorsan héjprogramozással. 


z Xdialog fejlesztése azzal a céllal indult, hogy 
A olyan programot hozzanak létre, amellyel a 

dialog vagy a cdialog adta lehetőségeket hasz- 
náló parancsfájlokat módosítás nélkül grafikussá vará- 
zsolhatjuk. Az Xdialog az említett alkalmazások összes 
elemét kezeli és ezek mellett számos újat is bevezet. 
Az utóbbiak között említhetjük a fájl- és könyvtárvá- 
lasztót, a fanézetet, a súgógombot - és még sorolhatnám. 
További előny, hogy az Xdialog a GIK-- eszközkészletet 
használja, így a segítségével létrehozott grafikus parancs- 
fájlunk alkalmazkodhat a felhasználó által választott 
asztaltémához. A projekt honlapja a 
2 http:/xdialog.dyns.net/ címen érhető el. 


Beszerzés és telepítés 

Az 57. CD Magazin/Xdialog könyvtárban található a legfris- 
sebb változat, amely a cikk írásának pillanatában a 2.1.1-es. 
A forrás .tar.gz és .tar.bz2 formában tömörítve, továbbá 
SRPM formátumban érhető el. Több felépítésre található 
előfordított RPM csomag is. A .deb csomagok egy kicsit 
lemaradtak az RPM-hez képest, ugyanis a 2.0.6-os volt 
közülük a legújabb. Az én Debian 3.0 r1 változatomban 
megtalálható 2.0.5-ös óta a napló tanúsága szerint nem 
történt sok változás, ezért a kipróbáláshoz is ezt használ- 
tam. A forrásból történő telepítés sem egy ördöngösség, 

a megszokott . /configure éréz make 88 make install 
biztos eredményre vezet. 


Általános használata 


Xdialog [-GTKt opciók:s] [cáltalános opciókz] 
ss [cdátmeneti opciókzsz] cdobozopciós ... 


vagy 
xXdialog ckülönleges opciós 


Az első esetben az [cáltalánosz] [-cátmeneti:] 

zcdoboz: sorozat tetszőleges számban ismétlődhet egyet- 

len Xdialog-sorban - ezt hívják dobozláncolásnak. 

Az általános és átmeneti beállítások (option) elhagyhatók, 

de utolsóként minden Xdialog-sorban egy dobozbeállí- 

tásnak kell szerepelnie. 

e Egy cáltalános beállítász minden utána következő 
cdobozbeál lítász-ra érvényes, amíg egy másik 
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cáltalános beállítász ki nem oltja a hatását. Ezek 
a beállítások az ablak címére, a gombok stílusára és 
hasonlókra vonatkoznak. 

e Az cátmeneti beállítások: csak a közvetlenül utánuk 
következő cdobozbeál lítász-ra érvényesek. Ezek a 
beállítások többnyire az adott doboz különleges tulaj- 
donságaira vonatkoznak. 

e A cdoboz beállítás: határozza meg, hogy az 
Xdialognak milyen elemet kell megjelenítenie. Legalább 
három értéket vár: egy szöveget, valamint a rajzolandó 
ablak magasságát és szélességét képpontban megadva. 


Amikor a felhasználó egy ablakot bezár, az Xdialog azt 

az eredményt egy vagy több karakterlánc formájában a 
szabványos hibacsatornára küldi. Egy általános beállítással 
ez a szabványos kimenetre is átirányítható. 

Az Xdialog visszatérési értéke hordozza magában az 
információt, hogy a felhasználó hogyan zárta be az utolsó 
ablakot. Ez lehet 0, ekkor az Ok vagy Igen gombra 
kattintott. 1 esetén a Mégsem vagy Nem gombot választotta. 


7. lista MI a neved? 


$1!/bin/bash 


DIALOG—-"/usr/bin/Xdialog" 
CIM-"Mi a neved?" 


NEVED- $DIALOG --title "$CIM" --stdout 
s3.--inputbox "Hogy hivnak?" 00 


case $? i1n 


0) 
$DIALOG --title "$CIM" --msgbox 
s "szia $NEVED!" 00 

10 
$DIALOG --title "$CIM" --msgbox 
sz "Talán legközelebb..." 0 0 

2550 
echo "Kilépés." 

esac 


255-ös visszatérési értéket kapunk, ha valami hiba történt 
vagy ha az alkalmazást az ablakkezelő rendszeren keresztül 
zárták be. lovábbi értékek is lehetségesek: a --help és 
--wizard átmeneti kapcsolók esetén. Dobozok láncolásakor 
az első olyan doboznál, amelynél a visszatérési érték nem 
nulla, a lánc megszakad. 

Amikor az Xdialogot különleges beállítással használjuk, 
semmilyen értéket nem vár el, mindössze adattal 
szolgál a szabványos hibacsatornán. Próbáld 
ki, mi történik, ha az Xdialognak nem 
adsz át más értéket, csak a --print- 
version-t! 


Szia, világ! 
Minden program itt 
indul. Lássuk, mire 
képes a --msgbox 
dobozbeállítás! 


$ xXdialog --msgbox 
"Szita világ! " 00 


Ne feledd, hogy az Xdialog 
program nevének az első 
betűje nagybetű. A --msgbox 
három értéket vár: az első az a 
szöveg, amely megjelenik a do- 
bozban. A továbbiak az ablak 
magasságát és szélességét jelölik ki, 
ezek értékeként adhatsz 0-t, ekkor az 
ablak önműködően akkora lesz, hogy a 

szöveg éppen beleférjen. Ha a szöveg sortörést 
tartalmaz, az az ablakban is ugyanúgy fog megjelenni. 
Ezenkívül a "nm" különleges karaktert használhatod 

a sortörések kijelölésére (1. kép, lásd a 71. oldalon). 


Mi a neved? 

Ezek után lássunk egy valódi alkalmazást! Egy olyan pa- 
rancsfájlt fogunk írni, amelyik megkérdezi a felhasználó ne- 
vét, majd kiírja a képernyőre (lásd az 1. listán és a 2. képen). 
Lássuk sorról sorra a parancsfájl működését! Az első 

sor mindössze a futtatandó parancsértelmezőt határozza 
meg - ez régi barátunk, a Bourne Again Shell. Az Xdialog 
nevét érdemes egy változóban tárolni. Előfordulhat, hogy 
úgy döntünk, nincs szükség a grafikus csillogásra, és 
megelégszünk a szöveges üzemmód nyújtotta menüve- 
zérelt felületekkel. Ekkor vissza kell térnünk a dialog 
vagy a cdialog használatához. Szerencsére ezek többé- 
kevésbé megfeleltethetőek egymásnak, a futtatandó 
program nevét azonban így is át kell írnunk. Ezt köny- 
nyebb egyetlen helyen megtennünk, mint az egész 
programban, ezért fontos az előrelátás. 

Mivel több ablakot használunk a programban és szeret- 
nénk ragaszkodni az egységes kinézethez, az ablakok 
címét is egyetlen változóban tároljuk. A következő sor 
már az Xdialoghoz fordul a név bekéréséhez. Az ismerős 

.  műveletjelet (operator) használjuk, ami az idézőjelek 
között szereplő parancsot futtatja és a kimenetét az egész 
kifejezés helyére helyettesíti be. Az Xdialog --stdout 


Lp Cal 


általános beállítása lehetővé teszi az alapértelmezésben 
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a szabványos hibacsatornára érkező adatok átirányítását, 
így a felhasználó által begépelt adat az ablak bezárása 
után a szabványos kimeneti csatornán fog szerepelni, 
s így a $NEVED változó tárolja. Ebben az új Xdialog-sorban 
egy új általános kapcsolót láthatsz, a --tit1le-t, amellyel 
az ablak címét írhatjuk át. 
A kérdésfeltevés után meg kell 
vizsgálnunk, hogy milyen módon 
zárta be az ablakot a felhasz- 
náló. Az Ok gomb meg- 
nyomása esetén a prog- 
ramnak másként 
kell eljárnia, mint 
a Mégsem gomb 
választásakor, ezért 
a $? különleges 
változó értékét 
vizsgáljuk meg. 
Ez a változó 
a bash-ben az 
utoljára futtatott 
program vissza- 
térési értékét 
tartalmazza. 
A fentebb emlí- 
tettek alapján 
választjuk szét az 
eseteket: normál 
esetben a név beí- 
rását az Ok gombra 
történő kattintás követi — ekkor 
egy üzenetdobozban köszöntjük a fel- 
használót. A Mégsem megnyomása esetén az udvariatlan 
felhasználótól névtelenül köszönünk el. Ha pedig a bal 
felső sarokban látható X-szel zárta be az ablakot, akkor 
csak a szabványos kimenetre írunk ki egy üzenetet. 


Hasznos beállítások 

Most csupán néhány fontosabb beállítást említenék meg, 
bár ezeknél jóval több létezik — mind megtalálhatod őket 

a kényelmesen használható HIML alapú leírásban. 

A dialog és cdialog parancsfájlokban a --backtitle 
cszövegs (általános) a beállítással a háttérre, azaz 
magára a terminálra lehetett fejlécet kiíratni. Grafikus 
felület alatt a háttérre nem illik írni, de a megfeleltethetőség 
érdekében a beállítást meg kellett tartani. A szöveg ezzel a 
beállítással jelenik meg az ablakban, majd egy elválasztójel 
után továbbiak követik. 


--allow-close ] --no-close (általános) 


A --allow-cilose alapértelmezett beállítás, az ablaknak 
az ablakkezelőn keresztül történő bezárását teszi lehetővé. 
Ebben az esetben az Xdialog 255-ös visszatérési értékkel 
ér véget. A --no-close megadása esetén az Xdialog 
figyelmen kívül hagyja az ablakkezelő bezárt eseményeit. 
Megjegyzendő, hogy az ablak a töröl esemény kiváltásá- 
val így is bezárható. 


--no-buttons (átmeneti) 


2004. március 69 


O Kiskapu Kft. Minden Jog fenntartva 


0 Kiskapu Kft. Minden Jog fenntartva 


2. lista Könyvtárfa mentése 
ft1!/bin/bash 
TITLE-"Könyvtárfa" 


MSG—" 


Ez a program egy könyvtárról készít egy listát. 


1. lépés: válaszd ki a könyvtárat 

2. lépés: válaszd ki az új adatbázist 
xdialog --title "$TITLE" --noclose --stdout 
s .--msgbox "$MSG" 0 0 


BACKTITLE- Válaszd ki a könyvtárat" 
DIR—- Xdialog --backtitle "$BACKTITLE" 
s.--title "$TITLE" --no-close --stdout 


5. -no-buttons --dselect "00. 
if [ 1 -eg $? ]; then 
exit 1 
fi 
f-1 


while [ 1 -eg $f ]; do 
BACKTITLE- Válaszd ki a célfájlt" 
FILE- Xdialog --backtitle "$BACKTITLE" 
s.--title "$TITLE" --no-close --stdout 
s5.--fselect "" 00. 
if L 1 -eg $?7 ]; then 

exit 1 

Fi 


if L -f $FILE 1]; then 
xXdialog --title "$TITLE" --no-close 
s .--stdout --default-no --yesno 
sz "A célfájl létezik. Felülírjam?" 0 0 

if L 0 -eg $? ]; then 
f-0 

fi 

else 
1-0 

fi 

done 


updatedb --localpaths-"$DIR" 

s -output—"$FILE"; echo "XXXX" I] 

xXdialog --title "$TITLE" --no-close --stdout 
53.--no-buttons --infobox "Kérlek, várj, 

s amíg elkészülök..." 00 


Ezzel a beállítással lehet elérni, hogy ne jelenjen meg 
az Ok vagy a Mégsem a --infobox dobozban, illetve a 
Könyvtár létrehozása, a Fájl törlése és a Fájl átnevezése 
gombok a --fselect, --dselect dobozokban. 


--default-no (átmeneti) 


A Nem, illetve a Mégsem gomb lesz az alapértelmezett, 
vagyis ami előre ki lett választva. 
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3. [IIsta Könyvtárfa böngészése 
ft!/bin/bash 


TITLE-"Könyvtárfa" 
BACKTITLE- Válaszd ki az adatbázist!" 


FILE- Xdialog --backtitle "$BACKTITLE" 
s5.--title "$TITLE" --no-close --stdout 


5 --no-buttons --fselect "00 
if L 1 -eg $? ]; then 

exit 1 
fi 


echo "Xdialog --title W$TITLEV" --stdout 
5 .--treeview W$FILEV" 0000 WVW" 5/tmp/dir$$ 
1-2; IFS-" 
PROGRESS-"Fa készítése..." 
locate -d "$FILE" W" I while read LINE; do 
while [ "" —— " echo "$LINE" I] cut -d/ 
s-f$i " 1]; do 
1- expr $1i - 1 
done 
üntii E" — " echo "LINE" [[/ cut  d/ 
s-f$i " ]; do 
echo -n " VW echo "$LINE" ] cut -d/ 
s -f-$i VM" ss /tmp/dir$$ 
echo -n " WV echo "$LINE" ] cut -d/ 
s-f$i V" ss /tmp/dir$$ 
echo " off expr $-2 W" 
ssss /tmp/dir$$ 
1- expr $i 41 
done 
echo -n 
done ] Xdialog --title "$TITLE" --progress 
5" $PROGRESS" 0 0 locate -d "$FILE" W" I 
s wc -[/ 


echo " 5" ss /tmp/dir$$ 
. /tmp/dir$$ 
rm /tmp/dir$$ 


Fontosabb dobozok 

Az alábbiakban tárgyalt dobozok jóval többre képesek, 
mint amennyit itt elárulok róluk. Nem mutatom be az 
összes kapcsolójukat és helyhiány miatt nem teszek 
említést az összes átmeneti beállításról sem, amelyekkel 
használhatók. 


--yesno cszövegs -magasságs cszélességsz 

A --yesno mindössze annyiban különbözik a --msgbox-tól, 
hogy egy Ok gomb helyett egy Igen és egy Nem gombot rak 
ki a szöveg kiírása után. 


--infobox cszövegs -magasságs cszélességs [-cidő:] 


Hasonlít a --msgbox-ra, de egy, a --no-buttons gombok 


ETETTTITTT 
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nélküli ablakhoz jutunk. lovábbá egy nem kötelezően 
megadandó időértékkel meghatározhatjuk, hogy hány 
ezredmásodpercig éljen az ablak, utána önműködően 
bezárul. Ha az időérték 0 vagy elhagyjuk, a doboz 
másként viselkedik: a szabványos bemenetről fogad 


üzeneteket. 


--progress cszövegs -magasságs cszélességs 
s [-max pont:] 


Ez egy olyan doboz, amelyben egy állapotjelző csík talál- 
ható. A szabványos bemenetről fogad üzeneteket. 

A cmax pont: által jelzett számú pontot vár és ennek meg- 
felelően növeli a csíkot. A cmax pont: elhagyása esetén 
alapértelmezésben 100-at vesz. Pontok helyett számokat 
is küldhetünk neki a szabványos bemeneten keresztül. 

Az ablak akkor zárul be, ha a szabványos bemenetre állo- 
mányvége jel érkezett, vagy a pontok száma, illetve az 
átadott szám átlépte a cmax pont: értékét. 


--treeview cszövegs cmagasságs cszélességsz 
ss clistahosszz ccímkeis celemis cállapoti 
s -mélységis ... 


Ez a doboz az átadott elemekből egy fát épít, amely 
legfeljebb 24 szint mélységű lehet. A ccímken: celemn: 
cállapotn: -mélységn: sorozat tetszőleges számban 
ismétlődhet. Egy elem mélysége az előzőnél legfeljebb 
eggyel lehet nagyobb, kisebb viszont akármennyivel. 

A clistahosszz mondja meg, hogy hány soros legyen az az 


alablak, amelyben a fát ki kell rajzolni; 0 megadása esetén ez 
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önműködő lesz. Az Ok megnyomása révén a szabványos 
kimeneten megjelenik a fa kijelölt elemének a címkéje. 


--fselect cállománysz -magasságs cszélességsz 
--dselect ckönyvtárs: -magasságs cszélességsz 


Ezekkel a dobozokkal a GIK- állományválasztóját érhet- 
jük el: egy állomány- vagy könyvtárnevet választhatunk 

ki velük. Az cál lományz és a ckönyvtár: beállítások az 
alapértelmezést jelölik ki. A --no-buttons segítségével 
tüntethetők el a Könyvtár létrehozása, a Fájl törlése és a Fájl 
átnevezése gombok. 


A hegycsúcs 

Most látni fogod, hogy mennyire egyszerűen lehet összetett 
feladatokat megoldani az Xdialog használatával. Két pa- 
rancsfájlt fogunk írni: az első egy tetszőleges könyvtár 
teljes szerkezetét menti (2. lista), a második képes az első 
által készített adatbázisokból betölteni (3. lista) a szerkeze- 
tet és egy fát készíteni belőle (lásd a 3. képen). 

Ha ismered a bash-t és figyelmesen követted az eddigie- 
ket, ezek a sorok nem jelentenek meglepetést. Az első a 
könyvtár és az adatbázis megkérdezése után leellenőrzi, 
hogy az állomány létezik-e, majd egy türelemre felszólító 
üzenet mellett elkészíti a könyvtárlistát. A második egy 
kicsit összetettebb: az adatbázis ismeretében a locate 
paranccsal az összes bejegyzést kiszedi belőle, s ezeket 
soronként feldolgozva egy átmeneti állományban előállítja 
az Xdialog-paranccssort. Ezt egy csővezetékkel oldjuk meg, 
az állapotjelző csík táplálásához azonban még szükség van 
egy csővezetékre. 
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Miért ne? 

Eddig csak az Xdialog mellett szóló érvekkel hozakodtam 
elő, ezért joggal megkérdezheted, hogy mikor fogok végre 
hibát keresni benne. Épp az előbb tettem meg. Ekkora 
méretű alkalmazásokat már nem gazdaságos bash-ben 
megoldani. Véletlenül se próbálj meg például CD-kataló- 
gust készíteni a fenti programokkal, mert napokig is eltart- 
hat, mire elkészíti a fát. Az Xdialog telepítő parancsfájlnak 
tökéletes megoldás. Ha fontos a csillogás, készíthetsz hajlé- 
konylemez-formázó programot és szép grafikus kabátot 
húzhatsz rá. Látni kell viszont a héjprogramozás korlátait: 
az előbbi feladat megoldása lassú és nem is szép. Egy szint 
elérése után nem kerülhető el, hogy megtanuld a grafikus 
felhasználói felületek készítésének a módjait. Oldd meg a 
feladatot C-H-t-ban, Javában, vagy -— ha közel állnak hozzád 
a parancsnyelvek - IcI/Ik-ban. 

Remélem, sikerült bemutatnom az Xdialog nyújtotta lehe- 
tőségeket. Ha te magad, a barátnőd vagy a felettesed szereti 
a grafikus felületet, és egy egyszerű, parancsfájllal önmű- 
ködővé tehető feladat áll előtted, az Xdialog a te barátod. 


Fülöp Balázs tadminoguardware.com) 

18 éves, imádja a Túró Rudit, a Debian Linuxot 
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Fájlkezelés - másként 


A kétpaneles fájlkezelőkről. 


izonyára mindenki találko- 
B zott már a KDE vagy a 

Gnome beépített fájlkezelő- 
jével, amelyben az ablak nagy részét 
ikonok formájában megjelenő könyv- 
tárak és más állományok foglalják el, 
a bal oldalon pedig néhány adatot 
olvashatunk róluk. Ez hatékony lehet, 
ha valaki az egeret szereti használni 
és minden csínját-bínját kitanulja a 
módszernek. Létezik azonban egy 
másik út is... 





A kétpanelesekről általában 

Aki még nem látott ilyen elrendezésű 
fájlkezelőt, annak merőben szokatlan 
lehet az elv: ugyanazon az ablakon 
belül két egymás melletti panelen két 
könyvtár tartalmát jeleníti meg lista- 
nézetben. Így az állományok neve 
fontosabb szerepet kap, mint az ikon- 
juk, sőt mint látni fogjuk, nem is fel- 
tétlenül szükséges ikont rendelni hoz- 
zájuk. A név mellett alapbeállításként 
az Összes kilistázott elemről részletes 
adatok jelennek meg (típusa, mérete, 
az utolsó módosítás dátuma). Közös 
tulajdonságuk még, hogy néhány 
egyszerű billentyűparancs elsajátítá- 
sával jelentősen fel lehet gyorsítani a 
munkát: a panelen belül az elrende- 
zésből következően a kurzorbillen- 
tyűkkel csak felfelé és lefelé lehet mo- 
zogni, a panelek között a IAB billentyű 
lenyomásával lehet váltani. Iovábbá 
megkönnyíti a dolgunkat, ha tudjuk, 
hogy állományt kijelölni az IÍNSERT bil- 
lentyűvel, az egyik oldalról a másikra 
másolni pedig F5-tel lehet. Az F6 bil- 
lentyűvel a kijelölt állományt áthelyez- 
hetjük, az F3, illetve F4 billentyűkkel 
pedig belenézhetünk vagy szerkeszt- 
hetjük őket. A fontosabb parancsok 
gyorsbillentyűi általában a képernyő 
alján vannak megjelenítve, de a leg- 


12 Linuxvilág 








1. kép 
A Portos Commander első pillantásra 
furcsának tűnhet zebracsíkjaival 


több esetben be tudjuk állítani ma- 
gunknak, hogy melyik billentyű lenyo- 
mására mit válaszoljon a program. 


A Pcmm -— a zebra 

A Pcmm tteljes nevén Portos Com- 
mander) első látásra kissé furának 
tűnhet, ugyanis fejlesztői alapbeállí- 
tásként csíkos hátteret adtak az állo- 
mánylistának. Ez abból a szempontból 
nagyon hasznos, hogy jól elkülöníti 
az egymás alatt látható bejegyzéseket, 
viszont, ha gyorsan haladunk lefelé, 

a felfelé futó zebracsíkok kissé össze- 
folynak. A név mellett szereplő kis 
ikonokat a KDE fájltípus-beállításai 
alapján rendeli az állományokhoz, és 
ugyanezen rendszer alapján ismeri fel, 
hogy milyen programmal lehet őket 
megnyitni. A Név oszlop szélességét 
önműködően növeli, ha olyan könyv- 
tárba lépünk, amelyben egy nagyon 
hosszú nevű állomány található, vi- 
szont amint elhagyjuk az adott könyv- 
tárat, nem csökkenti vissza a méretet. 
Ez azt eredményezheti, hogy bár a 
nevet jól látjuk, a többi tulajdonság 
eltűnik a látható mezőből, ezért kény- 
telenek vagyunk saját kezűleg csök- 
kenteni az oszlop szélességét vagy 

az alsó gördítősávot használni, ha 
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3. kép 
A Gnome Commander szemkímélő színekkel 


kíváncsiak vagyunk például a fájlok 
tulajdonosaira. Ha az egér bal gomb- 
jával egy állományt áthúzunk az 
egyik oldalról a másikra, megkérdezi, 
hogy másolni vagy áthelyezni szeret- 
nénk-e, esetleg csak egy hivatkozást 
hozzon létre a célhelyen, ami a for- 
rásra mutat. Jobb gombbal kattintva 
kellemes kinézetű menüt kapunk, ami 
minden bizonnyal ismerős: lehet me- 
móriába másolni, onnan beilleszteni, 
törölni, átnevezni, könyvtárat létre- 
hozni stb. A SPACE billentyű lenyomá- 
sára is kijelöli a fájlokat, de semmilyen 
kiegészítő adatot nem jelenít meg az 
adott könyvtárról vagy fájlról. A be- 
állítások menü viszonylag kevés lehe- 
tőséget ajánl fel, a könyvjelzők, a 
használt szövegszerkesztő és a fájlok- 
ról megjelenített adatok megadásán 
kívül semmi lényegeset. 


Krusader — a KDE lovagja 

Mivel a Krusader a KDE-csomag része, 
sok tekintetben függ tőle: ikonjait és 
fáljtársítás-tulajdonságait teljes egészé- 
ben a grafikus felület beállításaiból 
veszi, tulaadonképpen úgy viselkedik, 
mintha a Kongueror fájlkezelőt bújtat- 
ták volna más bőrbe. Jobb gombra való 
kattintással ugyanaz a menü látható, 
bal gombbal történő áthúzás esetén 
pedig éppúgy megkérdezi, hogy má- 
solni, áthelyezni vagy hivatkozást 
létrehozni szeretnénk-e, vagy mégsem 
csinálunk semmit. A bal gomb egyszeri 





kattintására az adott fáljt kijelöli. 
Másolás és áthelyezés közben a már 
jól ismert kis ablakocska mutatja, hol 
tartunk. A SPACE billentyű lenyomására 
ugyan nem jelöli ki az állományokat, 
ellenben van egy nagyon hasznos 
tulajdonsága: ha a fájl felett nyomtuk 
meg a billentyűt, akkor egy kis ablak- 
ban egyszerűen kiírja a méretét; ha 
viszont könyvtáron álltunk, akkor a 
könyvtár teljes helyfoglalását kiszá- 
molja az összes alkönyvtárával és tar- 
talmazott állományok méretével együtt. 
A Krusader rendkívül sok beállítási 
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lehetőséget ad: az eszközök menüben 
a Konfiguratort választva egy kellemes 
üdvözlőkép után a bal oldalon tudunk 
a különböző kategóriák közt lépkedni. 
Megadhatjuk, hogy milyen beállítá- 
sokkal induljon el, hogyan nézzen ki 
a felhasználói felület, illetve hogy 
milyen betűtípust használjon. 

Két olyan beállítási lehetőség is van, 
amelyekre külön is ki szeretnék térni: 
az egyik a fájlrendszerek önbefűzése 
a könyvtárfába (vagyis az automount). 
Ez olyan környezetben lehet hasznos, 
amelyben a rendszer nem támogatja 
az önbetfűzést; ilyen esetekben a 
Krusader az adott lemezt egy ideigle- 
nes könyvtárba fűzi be, mindezt szá- 
munkra észrevehetetlenül, majd 
amikor kilépünk a könyvtárból, le is 
választja. A Krusader másik hasznos 
tudása, hogy a tömörített fájlokat, 
mentéseket képes könyvtárként kezel- 
ni. Hasonlóan az előbbihez, ha itt 
belépünk egy archivált fájlba, akkor 
azt egy ideiglenes könyvtárba kicso- 
magolja, amelyben aztán szabadon 
mászkálhatunk, törölhetünk belőle, 
másolhatunk bele -— majd a könyvtár 
elhagyásakor a kiindulási helyen talál- 
juk magunkat az újra becsomagolt 

a fájllal, de immár az esetlegesen meg- 
változtatott tartalommal. 


Gnome Commander 

Miként a Krusader a KDE-vel, a 
Gnome Commarder - mint neve is 
mutatja — a Gnome grafikus felülettel 
áll szoros kapcsolatban: az alapértel- 
mezett programokat a grafikus felület 
beállításaiból nyeri, és a másolást is a 
kis felbukkanó ablakban követhetjük 
nyomon. 

Az egér jobb gombjával a szokásos 
menüt tudjuk előcsalogatni, a bal 
gomb viszont csak a kurzort mozgatja, 
az állományokat nem jelöli ki. A SPACE 
billentyűt lenyomva itt is a könyvtár 
teljes méretét ismerhetjük meg, de 
nem egy különálló ablakban, hanem 
a méret oszlopban, amelyben eddig 

a DIR: bejegyzés szerepelt. Amint 
elkezdünk valamit gépelni, az nyom- 
ban a parancssorban jelenik meg, és 
az ENTER lenyomására végre is hajtó- 
dik. A beállítási lehetőségek száma 
viszonylag nagy, külön megemlíteném 
a grafikus lehetőségeket: az alapértel- 
mezett , sötét háttéren világos betűk" 
témát lecserélhetjük annak fordított- 
jára, sőt akár valamennyi összetevő 


színét mi magunk adhatjuk meg. 
Kérhetjük, hogy például a különböző 
típusú állományok más-más színnel 
jelenjenek meg. FIP-ügyfélként is 
képes működni, és a hálózaton meg- 
osztott erőforrásokat is el tudja 
Sambán keresztül érni. 


mc — egy más világ 

A Midnight Commander egy kissé 
kilóg a sorból, hiszen eddig a grafikus 
felületen futó alkalmazásokat vettünk 
sorra, ezzel szemben a Midnight 
Commander karakteres felületen fut. 
Kinézete szinte egyáltalán nem ha- 
sonlít az eddig tárgyalt három fájlke- 
zelőre, csak az elrendezése és a műkö- 
dése azonos velük. Jó szolgálatot tehet 
azoknak, akik szeretnének megismer- 
kedni a konzol kínálta lehetőségekkel, 
esetleg grafikus felület nélküli számí- 
tógépen kell dolgozniuk. 

Szöveges állományok megjelenítésére 
és szerkesztésére saját programot 
használ (mcedit), a fájltársításokat 

a rendszer beállításaiból veszi. Kis 
erőforrásigényének köszönhetően 
nagyon gyors és hatékony. Ha valamit 
a parancssorba begépeltünk és a 
futtatása után kíváncsiak vagyunk az 
eredményére, nem kell minduntalan 
kilépni (ezt egyébként az F10 billen- 
tyűvel vagy az exit parancs beírásá- 
val tehetjük meg), elég megnyomni 

a CTRL-O billentyűkombinációt, és 
máris láthatóvá válik a szöveges felü- 
let. A kombináció ismételt lenyomá- 
sával vissza tudunk térni az mc-hez. 
Beállításokban itt sincs hiány: a színe- 
ket, a panelek elhelyezését, a mutatott 
fájltípusokat és még sok mindent mi 
magunk állíthatunk be. 


Végezetül 

Nem kívánok győztest hirdetni a 
kétpaneles fájlkezelők között, mivel 
ez nem egy teszt, másrészt mindenkit 
arra szeretnék bátorítani, hogy hasz- 
nálja őket, és találja meg a neki leg- 
megfelelőbbet. 

Kellemes próbálkozást mindenkinek! 


Nagy Lénárd 
(nagylenardaomonornet.hu) 
Másodéves hallgató a 

BME Neumann János infor- 
NN "I matika karán. Szabadidejét 
MESSSZI többnyire a barátaival tölti, 
hobbija a programozás és a néptánc. 
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Az ügyfél mindenekelőtt 


-Öd 


Előfordul, hogy a bor kevésnek bizonyul ahhoz, hogy üzletfeleinket boldoggá 
tegyük: kövessük nyomon az igényeiket, beleértve az értékesítés előkészítésével 
kapcsolatos tudnivalókat, a terméktámogatást és a személyes találkozókat Is. 


ostani írásom témája, Francois, a webalapú 
4 intelligencia. A mai menü tervezgetése közben 

már azoknak a lehetőségeknek a puszta száma 
is mellbe vágott, amelyeket ez a kifejezés eszembe juttatott. 
Téged is, mon ami? Igaz, hogy beszélhetnénk a webalapú 
mesterségesintelligencia-programokról, de én valami 
egyszerűbbre gondoltam. Enciklopédiák, üzletek közötti 
készletáramlások, szótárak, keresőmotorok, sőt még az 
elektronikus levél is. Igen, Francois, osztom a véleménye- 
det. A manapság tapasztalható rengeteg levélszemét okán 
az elektronikus levelezésben is megfontolás tárgyává válik 
az intelligencia. Mégis: az elektronikus levél a korszerű 
kapcsolattartás nélkülözhetetlen eszköze. Gondold csak 
meg, hogy az elektronikus levélhez szorosan kapcsolódva 
a csoportmunka-megoldások is egyre elterjedtebbek, és 
talán már kezded kapisgálni, hogy miért ezt választottam 
mai menünk témájául. 





Később kell folytatnunk, Francois, a vendégek megérkeztek. 


Bonjour, mes amis, isten hozott titeket Chez Marcelnél, 

a Linux világának legkitűnőbb éttermében és legjobb boros- 
pincéjében! Foglaljatok helyet, helyezzétek magatokat 
kényelembe - Francois azonnal hozza a bort. A borospin- 
cébe, Francois, déli szárny! Valami spanyol nedű kellene 
nekünk: a Bierzo Corullón 2000 tökéletes választás mai 
menünkhöz. 

Mielőtt megérkeztetek, Francois-val éppen a webalapú 
mesterséges intelligenciáról beszélgettünk. Üzleti szem- 
pontból nézve hajlok arra a véleményre, hogy a legfon- 
tosabb dolog mindig az ügyfelekkel kapcsolatos. Ügyfelek 
nélkül nincs üzlet, ebből következően igen nagy energiát 
kötnek le az ügyfélkapcsolatokat ápoló rendszerek. És itt 
jönnek a képbe a CRM (customer relationship manage- 
ment, ügyfélkapcsolat-kezelő) programok: ezek a progra- 
mok mindenféle adatot összegyűjtenek az ügyfelekkel kap- 
csolatban, az alapvető kapcsolattartási részletektől kezdve 
az eladási, marketing- és támogatási adatokig. Ezeket az 
ismereteket felhasználva a vállalatok az ügyfelek igényei- 
hez igazodva hozhatnak létre feladatokat és emlékeztető- 
ket. Ez lehet egy bizonyos termékkel kapcsolatos telefonhí- 
vás, egy kérés kezelése, reklamáció intézése, egy találkozó 
időpontjának a megbeszélése vagy bármi más, az ügyfelek- 
kel kapcsolatos teendő. A CRM-rendszerek a méretüket 
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1. kép A CRM-ctt főképernyője, amely felügyeleti és beállítási 
lehetőségeket kínál 


tekintve a nagyon egyszerűektől a rendkívül összetett, 
teljes céget lefedő, adatbányász behemótokig terjedhetnek. 
Az áruk is hasonlóan nagy szórást mutat az ingyenes vagy 
nagyon olcsó programoktól kezdve a többszázezer dolláros 
rendszerekig. Már e vonatkozás alapján is képet alkotha- 
tunk arról, hogy milyen fontosságot tulajdoníthatnak az 
üzleti életben az ügyfélkapcsolatoknak. 

Itt, a mi kis Linux-konyhánkban a nyílt forrással dolgozó 
programozók segítségével belekóstolhatunk néhány CRM- 
rendszerbe, anélkül, hogy ez a ráfordított időtől eltekintve 
bármibe is kerülne. 

Az első CRM-csomag, amit szemügyre szeretnék venni, 

a CRM customer tracking system (CRM-ctt, azaz a CRM 
ügyfél-nyomkövető rendszer) nevet viseli. Webes alapfelülete 
annyira egyszerű, hogy az embert arra késztetheti, hogy ne 
is foglalkozzon vele — bevallom, majdnem én is így jártam. 
Pedig egyszerűsége mögött egy jó képességű CRM-rendszer 
rejtőzik. Több felhasználó és többféle nyelv kezelését foglalja 
magában, továbbá gazdag paraméterezhetőséget, biztonsági 
beállításokat, elektronikus levélben érkező emlékeztető 

és PDF formátumú jelentések készítésének a lehetőségét, 

s ezekkel a tulajdonságaival a CRM-ctt mély benyomást 
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ku k : a header.in.php engedélyét a 777-es értékről váltsuk vissza 

asz esse aA NE a ÁMOEENTI Ír TI Frrésza hi 4.4 4. ű 

gé éig láv ék lőj sav áe Héé ére 755-re. Most menjünk az oldal aljára: kattintsunk a When 
Léna ) [d erne makyotásem er étetee dáme ág áree eber veztsátmetir [4] done, point your browser here (Amikor kész, irányítsd ide a 

ha . "1 böngésződet) kiemelt feliratra, ami a beléptetőképernyőre 

: Brr mage De: a E MÍ ZT ELETEN 

rang ; 5 ( visz bennünket. A belépéshez a rendszergazdai nevünket 

és jelszavunkat használhatjuk. 

Egy ilyen rendszert nem igazán tudunk ügyféladatok 

nélkül használni, úgyhogy lássunk is hozzá a beírásukhoz. 

Kattintsunk a Customer (ügyfél) fülre, majd a megjelenő 

oldalon kattintsunk az Add a customer (ügyfél felvétele) 
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HEZ féleténétát ! feliratra. Ismételjük meg a műveletet az összes ügyfelünkre 
dltántéte ő a a ra ren [ma vonatkozóan! Ha ügyfeleink adatainak a felvitelével készen 
al 7 at Jansz ! ; 7 .. "] vagyunk, akkor már ügyeket (Entities) is létrehozhatunk 
zer —E— gi jeti hozzájuk. Egy ügy bármi lehet, amit az adott ügyféllel 
úlndtltttme kk — at] kapcsolatban tennünk kell: egy folyamatban lévő rendelés, 
egy hibajegy (trouble ticket) megnyitása, egy barátságos 
2. kép A CRM-ctt egyszerű jelentéskészítési és egy kattintásra emlékeztető telefonhívás vagy virágküldés valakinek a 
működő PDF-export lehetőségeket teremt születésnapjára. A CRM-ctt még elektronikus levél küldé- 
sével is képes emlékeztetni a felhasználót ezekre a teen- 
gyakorol kipróbálójára (1. kép). A program egy példányát dőkre. A CRM-ctt felfedezése során megismerhetjük a 
a 5 http:/crm-ctt.sourceforge.net címről tölthetjük le. program nagyszerű jelentéskészítő képességeit is, amellyel 
A rendszer üzembe helyezéséhez és futtatásához egy futó, . többek között profi színvonalú jelentéseinket exportál- 
PHP- és MySOL-támogatással rendelkező Apache-kiszol- hatjuk egy kattintással PDF-állományba. 


gálóra van szükségünk. Amennyiben a CRM-ctt grafikus . e 

támogatására is igényt tartunk, a php-gd csomagot is telepí- ts alten Éj jirszmezán. Tanár. Kezem dtlezan. fáj 

teni kell a rendszeren. A telepítés több lépésből áll, de Fel Káta ete etre há elerly ák E HE. 
egyáltalán nem bonyolult: a csomagot bontsuk ki webki- zi júl ET ed 7 jú Hi úr di 

szolgálónk dokumentumkönyvtárának a gyökerébe. Való- Hvt A a 1: vés ustztelulkée ai v 
színűleg a könyvtár nevét is meg akarjuk majd változtatni:  Í 
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I 
cd /var/ww/html i kezi 
tar -xzvf crm-1.9.2-19102003.tar.gz 


mv crm-1.9.2-19102003 crm 
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Mielőtt folytatnánk, a CRM könyvtár tulajdonosának 
állítsuk be webkiszolgálónk felhasználónevét és csoportját. 
Ez az én esetemben a chown -R apache . apache crm parancs 
kiadását jelentette. 

Folytassuk a program beállításaival! Kezdjük azzal, hogy 
böngészőprogramunkat arra a helyre irányítjuk, ahova a 
programot telepítettük (olyasmit kell címként megadnunk, 3. kép Az eGroupWVare kínálatában naptárt, hibajegykezelő 
mint 5 http:/www.webkiszolgalo.dom/crm). Ezután a rendszert és felhasználói webhelykezelést is találhatunk 
program egy csomó beállítóképernyőn vezet végig bennün- 
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ket, ezek közül utolsóként a vállalat adattárházát kell létre- ! kel ele öle tes kért 
hoznunk. Kövessük tovább a lépéseket: adjuk meg a ad reb e al fiz ak EZEL Fid di 
nevünket, a rendszergazda nevét és levélcímét, valamint J a: ; 
a kiválasztott rendszergazdai jelszót. Mindössze négy Elesett J aa 3 HA ata tag gs ts ád ri ál v: 
webalapú lépésről van szó. [7 — 
A telepítési folyamat befejező lépése a beállítások lemezre 
íratása. A javasolt megoldás erre a header.inc.php fájl jogo- VS ÚSSEB ( azmza 7-8 
sultságainak ideiglenes megváltoztatása: ua firnlni [tree at 

(etel. , dm HÚ 

B B MT ázik 

cd /var/ww/html/crm MEZ ame 


chmod 777 header.in.php mt sar ál sake 


Kafka Fű 


AN kai pre ir 


Térjünk vissza a telepítési oldalra és kattintsunk a Iry Now 
(kipróbálás) feliratra. Ha minden jól megy, üzenetet kell 
kapnunk a sikeres befejezésről. Választhatjuk a fájl előál- 
lításának és a CRM telepítési könyvtárába való kézzel 


bemásolásának módját is. Ha ezen a lépésen túlvagyunk, 4. kép Egy hibajegy megkezdése az eGroupWare-ben 
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Mivel a CRM képes rá, hogy az alkalmazottakat figyelmez- 
tesse arra, hogy kivel mikor kell találkozniuk, fel kell ven- 
nünk egy bejegyzést a cron-ba is, hogy ezeket az elektroni- 
kus levélben érkező emlékeztetőket ki tudja küldeni. Ennek 
az az érdekessége, hogy a leveleket küldő kiszolgálónak 
nem feltétlenül kell a CRM-ctt programot futtató gépnek 
lennie. Én most csak egyetlen bejegyzést fogok mutatni 
(reggel 8 órára), de a figyelmeztető eljárást annyiszor futtat- 
hatjuk, ahányszor a cégünk szempontjából szükségesnek 
látjuk. A következő példában látható vourCRONpwd jelszó 
a CRM-ctt főoldalán lévő Administration (felügyelet) me- 
nüjében állítható be, a Change global systems values (az 
általános rendszerértékek megváltoztatása) menüpontban: 


ft CRM Alarm date manager 

0 8 " " " wget http://ww.webkiszolgalo.dom/crm/ 
3 duedate-notify-cron .php?password-yourCRONpwdN 
— €reposnr-XXxXx 15 /dev/null 25 /dev/null 


Rendszergazdaként további felhasználói fiókok létrehozá- 
sára van lehetőségünk, ilyen módon cégünk más tagjait is 
megbízhatjuk az egyes feladatok végrehajtásával. A felü- 
gyeleti képernyőről a teljes ügyféladatbázisra vonatkozó 
vezetői jelentések létrehozására nyílik lehetőségünk, ame- 
lyek szintén exportálhatók PDF formátumú jelentésekként. 
Mindezek végrehajtásához a CRM-ctt hálózaton keresztül 
elérhető kezelői leírást kínál. 

Számos CRM-csomag futtatható Linuxon, s ezek mindegyi- 
kére jellemző, hogy a tevékenységük középpontjában az 
ügyféllel való kapcsolattartás nyomon követése áll. Köze- 
lebbről megvizsgálva mégis az az érzésünk támadhat, hogy 
a CRM-csomagok nagymértékben hasonlítanak a korszerű 
webalapú csoportmunkát támogató programcsomagokra. 
És nem is gondoljuk rosszul. Egy jól működő CRM-rend- 
szer számos eleme megtalálható egy jó csoportmunka-prog- 
ramban is. Ami a csoportmunkaprogramot mégis megkü- 
lönbözteti, az az általa nyújtott webalapú intelligencia 
területe és az azáltal megnyíló, együttműködést támogató 
lehetőségek. A csoportmunka-programcsomagok központi 
elektronikus levelezéssel, naptárakkal, címjegyzékekkel, az 
eszmecseréknek teret adó fórumokkal, hívás-nyomonköve- 
téssel, és még számos egyéb programmal rendelkezhetnek. 
Az egyik ilyen csoportmunkacsomag, amely igen érdemes a 
vizsgálatra, az eGroupWare. 

Az eGroup Ware nyílt forráskódú API-val rendelkező 
GPL-programcsomag, így könnyen hozhatunk létre és ad- 
hatunk további programokat a rendszerhez. A programok 
között elektronikus levelezőrendszert, naptárt, naplózó 
rendszert az ügyfélhívások és teendők nyilvántartására, 
hibajegyrendszert (trouble ticket system), személyes és 
szervezeti telefonkönyvet, tudásbázist, egy wiki-dokumen- 
tációs rendszert, és még sok egyebet találhatunk. Ezenkívül 
webhelykezelő rendszert is tartalmaz, amellyel az egyes 
felhasználók elkészíthetik a saját oldalaikat. Mindezekre 

az eGroupWare képes, miközben takaros, munkára kész 
felületet is a magáénak mondhat (3. kép). Írásom születése- 
kor (2003 novemberének az elején) az eGroupWare-t körül- 
belül két hét választja el 1.0-s változatának megjelenésétől 
(sajnos még mindig elválasztja ettől az a néhány hét, a 
jelenlegi változat az eGroupWare 1.0 RC3.) Az eGroupWare 
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támogatja a legelterjedtebb nyílt forrású adatbázis-formátu- 
mokat, a MySOL-t és a PostgreSOL-t. A kipróbáláshoz 

a PostgreSOL-t választottam, de bármelyik könnyen beál- 
lítható. Ha be szeretnénk szerezni az eGroupWare egy 
példányát, a csomagot megtalálhatjuk az 57. CD 
Magazin/Fogado könyvtárában. Ezen az oldalon remélhe- 
tőleg megtalálhatók a mindenki számára megfelelő csomag- 
ok. A csomagot a tar.bz2 fájlból és először bontsuk ki 
webkiszolgálónk dokumentumkönyvtárának a gyökerébe. 
Például egy alapértelmezett Apache-telepítés esetén ennek 
a könyvtárnak a /usr/local/apache/htdocs elérési útvonalon 
kell lennie, de egy RPM-alapú telepítésnél (mint amilyen 

a Red Hat) ez gyakran a következő: 


/var/ww/html könyvtár : 
cd /var/ww/html 
tar -xzvf eGroupWare-változatszám.tar.gz 


Ez a lépés egy egroupware nevű könyvtárat hoz létre. 

A könyvtár engedélyeit változtassuk meg, hogy a webki- 
szolgálónk jogaival teljes körűen hozzáférjünk; ez nálam 
a következőt kjelentette: 


chown -R apache.apache egroupware 


Feltéve, hogy PostgreSOL-t szeretnénk hozzá használni, 

a következő lépés egy PostgreSOL-felhasználó létrehozása 
az adatbázis eléréséhez. Ezt a postgres felhasználónkra való 
váltással tehetjük meg: 


$ su - postgres 

$ createuser egroupware 

shall the new user be allowed to create 
databases? (y/n) y 

shall the new user be allowed to create more new 
users? (y/n) n 

CREATE USER 


Amikor a Shall the new user be allowed to create databases? 
(y/n) (Létrehozhat-e az új felhasználó adatbázisokat?) kér- 
désre kell felelnünk, adjunk igenlő (y) választ. Amikor azt 
kell megadnunk, hogy az új felhasználó létrehozhat-e új 
felhasználókat (Shall the new user be allowed to create more 
new users?), válasszuk az ,n" (nem) lehetőséget. Már csak 
egyetlen teendőnk maradt: hozzuk létre az adatbázist az 
eGroup Ware számára. Még mindig a postgres felhaszná- 
lóval bejelentkezve írjuk be a következő parancsot: 


$ createdb -U egroupware egroupware db 
CREATE DATABASE 


Ha az adatbázist nem szeretnénk egroupware-nek nevezni, 
tulajdonképpen akárminek hívhatjuk vagy egy kicsit meg 
is változtathatjuk a nevét, ahogy a fenti példában én is 
tettem. Ezzel parancssoros teendőinkkel készen is vagyunk, 
izzítsuk be a böngészőprogramot és véglegesítsük az 
eGroup Ware beállításait. Indítsuk el a Mozillát, a Kongu- 
erort vagy bármilyen más, Java-parancsfájlok futtatásra 
képes böngészőt, és webkiszolgálónkat irányítsuk a 

2 http:/webkiszolgalonk/legroupware/setup könyvtárra. 


A beállításokat tartalmazó fejállomány (header.inc.php) 
létrehozásához ezen a képernyőn írjuk be a beállításaink- 
nak megfelelő adatokat. Ha adatbázis-felhasználónknak 
nem az egroupware nevet adtuk, ne feledjük el itt azonosí- 
tani. Ugyanez vonatkozik az adatbázis nevére is. Itt kell 
beállítanunk a fejállományra (header.inc.php) vonatkozó 
jelszót és a rendszerfelügyelői jelszót. A fejállomány jelsza- 
vával módosíthatjuk vagy hozhatjuk újra létre a most 
létrejövő header.inc.php fájlt. 

Amikor ezzel is készen vagyunk, a setup/header (beállítá- 
sok/fejállomány) belépési képernyőjére jutunk. Egyszer már 
létrehoztuk a fejállományt, úgyhogy valószínűleg nem 
akarjuk újrakezdeni, non? Most tehát a pillanatnyi eGroup- 
Ware-beállítás érdekel bennünket. De mielőtt megtennénk 
ezt a lépést — úgy látom, sokan közületek üres pohár mellett 
üldögélnek. Francois, ha volnál kedves újratölteni; merci! 
Amikor a rendszergazdai jelszóval beléptünk, a beállító- 
program ellenőrzi, hogy az adatbázis rendben létrejött-e és 
hogy a fejállomány létrehozásának lépésekor megadott 
felhasználói azonosítót használjuk-e. Ha eddig a pontig 
minden rendesen Zajlott, a helyi beállítások első lépésénél 
(Step 1) kell tartanunk. Kattintsunk az Install (telepítés) 
gombra a program tábláinak létrehozásához és az eGroup- 
Ware programcsomag alkotórészeinek telepítéséhez. 

A rendszer néhány percig elrágódik majd ezen a feladaton. 
Amikor minden készen van, ellenőrizzük a böngésző 
ablakát, hogy nem kaptunk-e valamilyen hibaüzenetet, 
majd kattintsunk a Recheck my Installation (a telepítés 
ellenőrzése) gombra. Ha minden normálisan zajlott, 
továbbléphetünk a második lépésre (Step 2), és létrehoz- 
hatjuk admin felhasználói fiókunkat. Három próbafelhasz- 
náló létrehozására is lehetőségünk nyílik, de ez nem 
kötelező. A harmadik lépésben (Step 3) a használni kívánt 
nyelvet adhatjuk meg, míg a negyedikben (Step 4) az egyes 
programok saját beállításait végezhetjük el. Ebben a pár- 
beszédablakban dönthetjük el azt is, hogy az összes prog- 
ramot telepíteni szeretnénk-e (ez az alapértelmezett lehe- 
tőség) vagy válogatni kívánunk közülük. Amikor innen 
kilépünk, készen vagyunk a telepítéssel. 

Itt az ideje, hogy kezdjünk is valamit az eGroupWare-rel 

— ehhez legelőször is be kell lépnünk az admin felhaszná- 
lóval. Az a legvalószínűbb, hogy böngészőnket a 

2 http:/sajat.kiszolgalonk.dom/egroupware címre irányít- 
juk. A képernyő tetején végig ikonokat láthatunk, amelyek 
az egyes csoportmunka-szolgáltatásokat jelölik. A bal 
oldalon a pillanatnyi programnak megfelelő menük helyez- 
kednek el, de mindig látható egy kisebb menü a Home 
(saját hely), Preferences (beállítások), About (névjegy) és 
Logout (kijelentkezés) menüpontokkal. A kinézet és műkö- 
dés a saját ízlésünknek megfelelően módosítható a Preferen- 
ces (beállítások) menüpontra kattintva és ott a megfelelő 
változtatásokat végrehajtva. 


Amennyiben felügyeleti jogosultsággal rendelkezünk, teljes 
cégre vonatkozó változtatásokat is végrehajthatunk. Sőt 
arra is lehetőségünk nyílik, hogy a felhasználók által nem 
módosítható alapértelmezett beállításokat adjunk meg 

— ez nagyon hasznos lehet egy egész cég felügyeletét ellátó 
rendszergazda számára. A felhasználói fiókok létrehozá- 
sakor előre meghatározott programokat rendelhetünk 
hozzájuk, s ezzel egy csoportokon alapuló belépési rend- 
szer alakul ki; például a támogatói csoportnak valószínűleg 
a hibajegyeket kezelő rendszerre lesz szüksége (4. kép). 

Ez a csoportszemléletre épülő megközelítés átgondolt esz- 
közkészletet kínál felhasználóink számára. Először hozzuk 
létre a csoportokat, döntsük el, hogy mely programok 
használatára lesz szükségük, s ezután ezekre a csoportokra 
építve hozzuk létre felhasználóinkat. 

Az eGroupWare jövőjének és folyamatos támogatásának 
tekintetében elmondható, hogy a programcsomaghoz 
pezsgő fejlesztői és felhasználói közösséggel bír, számos 
levelezőlista és IRC-csatorna érhető el arra az esetre, ha 
felmerülő kérdéseinkre válaszokat keresnénk. 

Mon Dieu! Már megint kifutottunk az időből. Sajnos a hely 
és az idő nem engedi, hogy mást is részletesen megvizsgál- 
junk, pedig nagyon sok kitűnő programcsomag létezik 
még, amelyek érdemesek lennének a figyelmünkre. Habár 
mindnyájan szeretünk a Linuxszal főzni, szerény meglátá- 
som mégis az, hogy a mi vendég-vendéglátói viszonyunk 
nem igényel számítógépes programot. Ehelyett inkább 
kényelmes székeitekkel és kedvenc asztalaitokkal várlak 
titeket, Francois pedig ügyel arra, hogy a poharatok mindig 
tele legyen. Néha az egyszerűség a legfőbb erény. Francois, 
ha volnál szíves gondját viselni a vendégeinknek! A követ- 
kező alkalomig, mes amis, ürítsük poharainkat egymás 
egészségére! A vötre santé! Bon apétit! 


Linux Journal 2004. február, 118. szám 


Marcel Gagné (mggagnesalmar.com) 
Mississaguában, Ontario államban él. 

Ő a szerzője a Kiskapu kiadásában tavaly szep- 
temberben megjelent Linux-rendszerfelügyelet 
(ISBN 96-9301-40) című könyvnek. 





CRM-ctt 3 http://crm-ctt.sourceforge.net 
eGroupWare 3 http:/Avwvw.egroupware.org 
Marcel borlapja 

2 http:/Avww.marcelgagne.com/wine.html 
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A szinte tökéletes játék: az Unreal 


Anno 1996-ban a játékosok körében felröppent a hír, hogy olyan játék készül, 
ami új fejezetet nyit a számítógépes játékok történetében. 
Egészen pontosan olyan grafikája lesz, amilyet még soha senki nem látott. 





zután 1997-ben elkezdtek 
szállingózni a képernyőké- 
pek és a fejlesztői leírások, 


végül egyszer csak minden ilyesmi 
megszűnt. Mindenki úgy könyvelte el, 
hogy ez is csak egy olyan kezdemé- 
nyezés volt, ami valahol az íróasztal- 
fiókban végzi, hiszen a technika 
akkori szintjén a feladat megvalósítha- 
tatlannak tűnt. 

1998 volt az az év, amikor bombaként 
robbant a hír: megjelent az Unreal. 

A szaksajtó azonnal többoldalas leírá- 
sokat, elemzéseket szentelt neki, és 
egybehangzóan hihetetlennek és le- 
nyűgözőnek vélte. 

Ekkor látott napvilágot az a játékmotor, 
amelynek igazán komoly vetélytársa 
csak évekkel később született meg, és 
amelynek képességeit a Ouake3-ban 

— szinte elhűlve - figyeltük. 


Maga a játék 

A játék lelke a világ első Unreal-mo- 
torja, amely a maga idejében forra- 
dalmi volt. Világosan látszik, hogy en- 
nek a fejlesztők nagyon is tudatában 
voltak, és olyan játékot készítettek, 
amely , lechDemo" jelleget kölcsönöz 
neki. Egyaránt találkozunk Highlech- 
környezettel és ősrégi, komor kastély- 
lyal, labirintussal, katedrálissal, vala- 
mint földönkívüli látvánnyal. Mindez 
lenyűgöző fénykezelési eljárásokkal 
van megtűzdelve, ami miatt bizony 
elvakíthat bennünket a nap, vagy 
éppen félhomályba borul a táj, mert 

a nap elé egy felhő úszik. Ebben a 
lechDemo-hangulatban a történet 
szinte elsikkad (ami szerint egy rab- 
szállító űrhajó zuhan le a bolygóra, 

és az egyetlen feladat: elszabadulni 
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innen) — még bevezető animáció 
sincsen, mindössze egy ősi kastély 
körül lebeg egy kamera. 

A játék meglehetősen hosszúra sikere- 
dett, ami előnyére vált, bár a vége felé 
egy kicsit egyhangú kezd lenni a já- 
tékmenet — mindezt feledteti azonban 
a hangulat. A játékban teljesen kidol- 
gozott élővilágot látunk: madarak 
szállnak az égen, halak úsznak a vi- 
zekben, a szárazföldön pedig kisebb- 
nagyobb élőlények legelésznek. Ellen- 
feleink még ennél is változatosabbak: 
több méretben és felszereltségben 
találkozhatunk Ska-Arj harcosokkal, 
akik nem restek átküldeni bennünket 


E EZEL ZENE 


si TTET 4 ERENVK MU FK PG EE 


Fra agwa káfü ká kirémzeza erű Táj ani 


Hl öss mag serif erem EE 
Fedlmür Ún FEB 


Desztnszag] [ans ] 


e] 


az örök vadászmezőkre, ha tehetik. 
Ugyanakkor - a hasonló kategóriájú 
játékoktól eltérően — nem mindenki 
ellenség. A négykezű, békés Nalik 
kifejezetten barátságosak, és ha meg- 
mentjük valamelyiküket, általában 
mutatnak nekünk egy titkos zugot, 
ahol igen combos tárgyakat lehet 
felvenni. Érdemes tehát a védel- 
münkbe venni őket. 


Grafika, hangok, hangulat 

Ezek azok a dolgok, amelyekre egy- 
szerűen nem lehet panasz. A látvány 
jelenleg már nem képviseli a technikai 
csúcsot, de az elsőrangú LevelDesign 
olyan hangulatot teremt, amelyben 
ezt észre sem vesszük. (Igazából ez 
már nem az eredeti motor, de erre a 
későbbiek folyamán kitérek.) A képek 
magukért beszélnek... A zene fantasz- 
tikus módon részét alkotja a játéknak 
- én a mai napig nem hallottam ennél 
jobb Zenei aláfestést. lermészetesen 

— akkoriban úttörő módon - dinami- 
kusan alkalmazkodik az események- 
hez, tehát békés mászkálás vagy harc 
közben más-más zenét hallunk. 





Néhány technikai apróság 

Fontos dolog megemlíteni, hogy ez 
sehogyan sem lesz az ,eredeti" 
Unreal. Ugyanis furcsa — de mégis 
okos — módon egy előtelepített Unreal 
lournamentre van szükség a futtatá- 
sához (ez meg is látszik a grafikán). 
Ezzel ebben a régebbi játékban is 
némi technológiai fejlődéshez jutunk. 
Figyelemünkre méltó viszont egy, a 
telepítőcsomaghoz való bővítmény. 
Ez pedig nem más, mint az ACID- 
meghajtó, amely nagy sebességet tesz 
lehetővé a régebbi videokártyákon. 
Ezzel 1024 x768-as felbontást is el tu- 
dunk érni egy régebbi Voodoo2 vagy 
INT kártyán, ugyanakkor kihangsú- 
lyoznám, hogy az újabb kártyákon 
csak ront a helyzeten. Sokat tanakod- 
tam, miért az történik, hogy úgy hul- 


lámzik tőle a kép, mintha víztükrön 
keresztül néznék. Lehet, hogy a beállí- 
tásaimmal nincs rendben valami, vagy 
elképzelhető, hogy ez a meghajtó nem 
nVidia alapú kártyákhoz készült 

(és ezért nem szereti a Geforce2 kár- 
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tyámat), vagy egyszerűen csak , túl 
gyors" lesz, azaz túlpörög. Én az 
utóbbira tippelek. A meghajtó nagyon 
jó és kegyetlenül gyors. Sajnos a 
Readme egy kicsit szegényes ez 
ügyben és nem is túl közlékeny; 
mindössze annyit tartalmaz, hogy mit 
és hol kell átírnunk (erre még a tele- 
pítés után visszatérünk). 


A játék telepítése 

Mint már említettem, nagyon fontos, 
hogy még az Unreal telepítése előtt 
legyen egy működőképes Unreal 
lTournament-példányunk (nem a 
20031). Ha ez megvan, akkor mind- 
össze az Unreal I csomagra lesz 
szükségünk, amit a 

2 http:/www.icculus.org oldalról le 
lehet tölteni. Látni fogjuk, hogy itt 
található még a küldetéslemez 

, Return to the Na Pali" és , Unreal- 
Gold" telepítője is. 

A telepítés pontosan ugyanúgy Zajlik, 
mint azt az Unreal lournament ese- 
tében már megszokhattuk, tehát 

a supermount rendszert ki kell kap- 
csolni és az Unreal CD-t kézzel kell 
befűzni. Sajnos a szokásos Loki-tele- 
pítőről van szó, tehát erre itt is oda 
kell figyelni, ugyanis csak ebben az 
esetben látja a telepítő a forrás-CD-t. 
Ha a szokásos telepítési lépéseken 
túl vagyunk, érdemes megjegyezni 
a következőket: a telepítő a 
/usr/local/games könyvtárban egy 
unreal nevű könyvtárat hoz létre, 





mint azt az eddigiekben megszok- 
hattuk. A CD-ről telepíti a zenéket, 

a textúrákat és egyebeket. A játék 
motorjára és annak beállításaira 
azonban csak hivatkozásokat hoz létre 
a Tournament könyvtárból. Sőt 

a rejtett könyvtárként megjelenő 
.loki/unreal könyvtárban (ezt a /home 
alatt keressük) a tournament.ini fájl- 
jával találkozunk, amit bátran szer- 
keszthetünk. Ennek eredményekép- 
pen az unreal indításakor az UT 
menürendszerével találkozunk, 
ugyanis a helyzet az, hogy valójában 
az UT indul és az Unreal modként 
(modification) fut benne. Ennek hatá- 
sára az Unreal grafikája valamivel 
szebb lesz, ugyanakkor az lesz a do- 
log hátránya, hogy a gépigény a lour- 
nament gépigényével egyezik meg. 
Az Unreal fantasztikus játék, kipróbá- 
lása mindenki számára kötelező, aki 
számítógépes játékokkal múlatja az 
idejét. Ez a játék is etalon lett a későb- 
biekben, mint ahogyan a Ouake volt 
annak idején vagy a Half-Life lett az 
elkövetkező időkben. Aki még sosem 
próbálta, bátran vágjon bele, mert 
nem mindennapi élménnyel gazda- 
godhat; aki pedig már ismeri, ezúttal 
Linuxon is nosztalgiázhat. Azokban 

a régi szép időkben még a játék adta 
el a játékot, és nem a marketing. 
Habár Deathmatchben gyengécske 
(arra ott van a lournament), az Unreal 
fő ereje az egyjátékos mód. 

További jó szórakozást kívánok hozzá! 


Dancsok , strogg" Zoltán 
(stroggaomaill.tvnet.hu) 
Jelenleg technikai szerkesz- 
tőként dolgozik a 
BME-OMIKK-nál, ahol oktat 
is. Emellett egyetemi 
képzésben vesz részt, programozó matema- 
tikus szakon. Négy éve foglalkozik Linuxszal. 
Szabadidejében operációs rendszereket 
gyűjt és weblapot vezet. 
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Cyeling 
A Cycling a kerékpárosedzést segíti: 
nyilvántartja a megtett körök számát, 
a legnagyobb sebességet, a távolságot 
és az egyéb adatokat. Noha eredetileg 
kerékpározáshoz tervezték, bátran 
használható futáshoz, úszáshoz vagy 
bármilyen sporthoz, ahol rögzíteni 
akarod az időt, a sebességet és a távol- 
ságot. Futtatásához szükséges: libgtk- 
x11-2.0, libatk-1.0, libgdk-x11-2.0, 
libgdk pixbuf-2.0, libm, libpangoxft- 
1.0, libpangox-1.0, libpango-1.0, 
libgobject-2.0, libgmodule-2.0, libdl, 
libglib-2.0, glibc, libXi, libXext, libXft, 
libXrender, libfontconfig, libX11, 
libfreetype, libz és libexpat. 
2 http://juvenis.dyndns.org/ 
index.php?dirid— Idrartid—3 


handwidthed 

Az egyetlen ok, ami miatt a band- 
widthd az MRIG vagy a Cacti helyett 
ajánlható, az az, hogy a bandwidthd az 
egyedi IP-címeket ábrázolja, nem háló- 
zati adatokat rögzít. lovábbá gazda- 
gépenként megpróbálja osztályozni a 
TCB UDB ICMP VPN, HTIP vagy P2P 
típusú forgalmat, vagyis láthatóvá 





válik, hogy az egyes gazdagépek mi- 
lyen forgalmat bonyolítanak az általuk 
használt sávszélességen. Előfeltételei: 
libgd, libpng12, libpcap, glibc, libxpm, 
libX11, libjpeg, libíreetype, libz, libm, 
valamint a libdl. 

2 http:/bandwidthd.sourceforge.net 
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gtick 

Metronómra van szükséged? Ez a 
metronóm nemcsak egyetlen zenei 
ütemet ad ám, hanem választhatsz, 
hogy 2/4-es, 3/4-es vagy 4/4-es, sőt 
akár egyedileg beállított ütemet 
adjon-e. A ritmus és a hangerő 
tolókapcsolóval szabályozható, amely 
a nyers hangolást teszi lehetővé, 
valamint a finomhangolás érdekében 
tekerőgombbal is beállítható. 
Futtatás: libgtk-x11-2.0, libgdk-x11- 
2.0, libatk-1.0, libgdk pixbutf-2.0, libm, 
libopangoxft-1.0, libpangox-1.0, 





libpango-1.0, libgobject-2.0, libgmo- 
dule-2.0, libdl, libgthread-2.0, libglib- 
2.0, libpthread, glibc, IibXII, libXi, 
libXext, libXft, libXrender, libfon- 
tconfig, libíreetype, libz és libexpat. 
2 http:/www.antcom.de/gtick 


The Battle for Wesnoth 

Ez a játék egy háborús játék és egy 
szerepjáték kereszteződése, amelyben 
a karakterek hatszög alakú területegy- 
ségeken mozgathatók. A lények nem 





különösebben erősek, de nem egy- 
szerű eljutni a második pályára. 

A túléléshez találékonyságra és 
minden erőforrásodra szükséged lesz. 
Vigyázat, több órán át foglyul ejthet! 
Futtatásához szükségesek: libstdc-t -k, 
libSDL-1.2, libpthread, glibc, libm, 
libgcc s, libXII, libXext és libdl. 

2 http:/www.wesnoth.org 


S0L-Ledger 


Azt hiszem, nem láttam még olyan 
programot, ami olyan gyorsan és 
olyan mértékben fejlődött volna, mint 
az SOL-Ledger az elmúlt három 





évben, amióta használom. Ez a prog- 
ram teljes körű kettős könyvviteli 
szolgáltatást nyújt szinte bármilyen 
vállalkozás számára, méghozzá szá- 
mos nyelven. Aligha találnék ennél 
jobb könyvelési csomagot. 

Rendkívül egyszerűen telepíthető. 

Ha a gépen már telepítve van a LaleXx, 
a PDF-fájlokat közvetlenül kinyomtat- 
hatod, vagy elektronikus üzenetként 
küldheted el a számlákat és a bevallá- 
sokat. Az alapértelmezett beállítások 

a kanadai adórendszerhez igazodnak, 
de bármilyen más rendszernek 
megfelelően egyszerűen átállíthatók. 
Az egyik legnagyszerűbb szolgálta- 
tása, hogy az adatbázis PostgreSOL-t 
használ. Ha teljes könyvelési 
csomagot keresel a vállalkozásod 
számára, ezennel megtaláltad. 
Futtatásához szükséges: Perl, Perl- 
modulok - DBI, DBD (DBD-Pg vagy 
DBD-Oracle), PostgreSOL vagy 
Oracle, Perl-parancsfájlok futtatására 
alkalmas webkiszolgáló, webböngésző 
és LaleX (nem kötelező). 

2 http:/www.sgl-ledger.org 
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David A. Bandel 
(dbandelopananix.com) 
Jelenleg Panamában él, 
l Inux- és Unix-tanács- 
] adással foglalkozik. Társ- 
34 - szerzője a Oue Special 
Edition: Using Caldera OpenLinux 
című könyvnek. 





Linux bevetés közben 
Tavaly év végén egy olyan könyv jelent meg, 


amely a rendszergazdákat és rendszermérnököket célozza meg. 


elent már meg hasonló 
! témájú kiadvány, ez idáig 
azonban nem volt szerencsém 
olyan könyvet a kezembe venni, 
amely szakmai megközelítésként azt 
a fajta barkácsolást választotta volna, 
ami a Linux-rendszereknek olyany- 
nyira a sajátja. 


Tuningoljunk! 

A ,barkácsoljunk egy kicsit" stílus 
sokak számára ijesztő értelemmel bír, 
jelen esetben viszont mindenképpen 
rokonszenves a jelentése: 
kiszolgálóépítést és tuningolást takar. 
Itt a hangsúly a tuningoláson van, ami 
egy kicsit tudathasadásossá teszi az 
egészet, hiszen örökös harc folyik a 
programozók és a rendszergazdák 
között a tekintetben, hogy a progra- 
mozók az összes programból mindig 
a legújabbat szeretnék a kiszolgáló- 
gépen látni, a rendszergazdák pedig 
általában ragaszkodni szoktak a már 
jól bevált és üzembiztos (stable) válto- 
zatokhoz, amelyekhez biztonsági 
követés, valamint jó leírás is a rendel- 
kezésükre áll. Az író megpróbálja 
egyensúlyban tartani a két ellentétes 
igényt, azaz: építsünk olyan kiszol- 
gálókat, amelyek biztonságosak és 

, friss" programokat tartalmaznak. 

A tanácsok és ötletek a rendszer elin- 
dításától egészen a DNS üzemelte- 
téséig terjednek. 


Rugalmas SSH 

Először találkoztam olyan könyvvel, 
amelyik az SSH hihetetlenül rugalmas 
lehetőségeinek a teljes kimazsolázását 
olyan módon teszi, hogy akár egy 
középhaladó szakember is megérti, 
hogy mit és miért érdemes használnia. 
De akár az alagút-, a VPN- és a jail- 
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építés mesterfogásait is elsajátíthatjuk, 
vagy a szerző útmutatásai alapján 
magunk is ügyes kis héjprogramokat 
írhatunk. lehát minden linuxos 
korosztály számára ajánlható 
(akárcsak az Ablak—zsiráf). 


Nagy segítség 

A könyv első olvasásakor arra gondol- 
tam, hogy számomra már nem tarto- 
gathat szakmai újdonságokat, azon- 


0 Kiskapu Kft. Minden Jog fenntartva 


ban hamar rá kellett jönnöm, hogy 

a szerző olyan parancsokat ismertet 
meg velem, illetve olyan fajta kombi- 
nálhatóságukat mutatja be, amelyek 
azóta is nap mint nap megkönnyítik 
rendszerfelügyeleti munkámat. 

A kiadvány a következő témaköröket 
dolgozza fel: 

e a kiszolgálóépítés alapjai, 

e  változatkövetés, 

e biztonsági mentés, 

e — hálózatkezelés, 

e  rendszerfelügyelet, 

e azSSH, 

e a parancsfájlok, 

e — adatbázis-kiszolgálók. 


A könyv vége felé, amikor a DNS és 
az SSH beállításával ismerkedhetünk 
meg, a szerző egy kicsit szabadon 
fogja fel a biztonság kérdéskörét, a 
lektori megjegyzésekben azonban 
mindenhol szerepel jó tanácsként, 
hogy milyen biztonsági megfonto- 
lásokat érdemes betartani. Egyszóval 
ez egy igen átfogó könyv, amely 
teljesen rendhagyó módon közelíti 
meg az üzemeltetés fogalmát. 

A könyv oldala a Kiskapu Kiadó 
honlapján a 

2 http:/kiado.kiskapu.hu/51 címen 
érhető el. Itt megtalálható a tarta- 
lomjegyzék, letölthetők a mintaol- 
dalak és a könyvben szereplő kódok. 


Varga S. Csaba 
(guskaoguska.hu) 

Az 1.1-es Slackware óta 
linuxozik. Kedvtelései közé 
tartozik a fotózás és 

a Linux telepítése PDA-kra. 
Legszívesebben a Gerecsében 

túrázik a barátaival. 
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